When comparing Nested-Routes vs Servant, the Slant community recommends Servant for most people. In the question“What are the best Haskell web frameworks for building RESTful web services?” Servant is ranked 7th while Nested-Routes is ranked 9th. The most important reason people chose Servant is:
Ranked in these QuestionsQuestion Ranking
Pro Embed Attoparsec parsers and regular expressions in a routable url
If you have a data encoding you would like to allow as a path chunk, you can do so by routing with an attoparsec parser or regular expression directly.
Pro Nesting of Handlers
The ability to give a handler child handlers turns a list of handlers into a tree of handlers - much easier to maintain.
Pro Simple and Concise
Routing a RESTful api is very literal in Nested-Routes.
Pro Automatic documentation and Haskell/JS query generation
servant-client for Haskell.
Con Complicated Types
There is a lot of advanced language extensions in use for the engine - if you have a typo somewhere, the errors are practically impossible to understand.
Con Route definitions are more verbose and complicated than other options
You are required to define a number of separate complicated types and their implementations which are usually spread out over a number of files. This makes it hard to figure out the API.
Con Route specifications and implementations are only connected by their position in a large type list
You actually have to count the index of the entry where you changed the specification, and then go and change the entry at the same index in the list of implementation methods. There is no other indication that the two are connected. This along with complex and verbose route definitions, makes it very hard to safely make changes to an API.
Con No built-in authorization handling
Currently, authorization must be handled through some other package (or custom code). Managing authorization directly within Servant, including OAuth and other tokens, is under development.