I wrote Rosencrantz because I do not like the Jester API very much.
Jester, like many other frameworks, hardcodes exactly what to do with a Request - say parsing the headers, parsing the form if the content type suggests so, always return a date, and so on.
This is not bad per se, but I prefer to have something I can compose. Say, I have a working route `r`. If I want to add CORS support, for instance, I can just make a handler `h` that adds CORS headers and then use the route `h -> r`.
This is more flexible and leaves fine grained control over which headers to require, or return, how to do content negotiation, and so on. You can separate your routes for `POST` from those for `GET` in different modules and then combine them, or maybe separate your authentication routes from the business logic ones. You can easily create handlers that work as middleware, and so on.
In short, the thing I like about this approach is that handlers become first class objects that you can manipulate and create freely
Jester, like many other frameworks, hardcodes exactly what to do with a Request - say parsing the headers, parsing the form if the content type suggests so, always return a date, and so on.
This is not bad per se, but I prefer to have something I can compose. Say, I have a working route `r`. If I want to add CORS support, for instance, I can just make a handler `h` that adds CORS headers and then use the route `h -> r`.
This is more flexible and leaves fine grained control over which headers to require, or return, how to do content negotiation, and so on. You can separate your routes for `POST` from those for `GET` in different modules and then combine them, or maybe separate your authentication routes from the business logic ones. You can easily create handlers that work as middleware, and so on.
In short, the thing I like about this approach is that handlers become first class objects that you can manipulate and create freely