> How about error handling? This is a very general question, so I have to give a general answer. Application-level errors are expected to be thrown as excepti

> How about error handling? This is a very general question, so I have to give a general answer. Application-level errors are expected to be thrown as exceptions. Unknown exceptions will result in a 500, as usual, in particular to not leak any sensitive data. A FinishRequestException can be thrown to show a different response; it tells the framework: Act as if the handler returned this object. Errors in the incoming JSON (syntax errors as well as validation errors / mismatched structure) are reported to the client as 400, with validation messages and offending field paths included. Feel free to ask a more specific question, otherwise it's hard to tell what you are referring to. > How about security? This was not a focus for the first version. You can use servlet filters, but that's going to be like driving a screw with a hammer. The next version is intended to have framework-level filters that have access to higher level information than servlet filters, such as the matched route. Low-level security, such as resistance against malformed syntax in the HTTP request is the job of the servlet container. > This is something I would never write like this. get(0) is a big no-no, and this style also makes it hard to follow what's happening (what parameters / arguments there are), because the URL pattern is not next to this. This is something I'm working on to find a good way to express in code. Mostly, the basic idea is that the URL pattern is next to that code, because the two are tied to each other anyway. Note that using a String-named field in the URL is better for readability, but just as likely to break when the code is changed.