I’ve written a horribly overengineered REST API using Servant. The API lets you create, update and delete counter values.
Given that it’s admittedly overcomplicated and overengineered, why bother posting it here? Two reasons:
-
It might still serve as an example of the named routes feature in Servant. I think named routes are a huge jump in usability for Servant APIs and can’t imagine going back to positional routes.
-
I’m interested in simpler ways of scratching some of the itches which prompted me to build the example. In particular:
-
What is the best way of keeping the Servant API and the domain model separate? When should we kept them separate? Is it ok in most cases to reuse our domain model datatypes for the API?
-
When I log from my domain model, I want the log messages to include the current Servant route. But I don’t want my domain model to be aware of Servant at all. Only the logger implementation should be aware that routes exist.
I solved this by using a form of dependency injection plus some typeclass magic. But I would be interested in other ways of going about it (that still don’t require polluting my model with knowledge of Servant).
-