Parse URI back into Route

[tysonzero]

I am using Servant for interacting with third parties, and it's not uncommon to encounter URIs in the returned content, particularly URIs that refer to routes I have already mapped out.

At the moment I have to manually parse the values I need out of the URI and then call the appropriate servant-client function. But that seems to partially defeat the point of Servant and the idea of encoding routes as types. It would be great to have functions that are basically the inverse of those in Servant.Links, returning the parameters in an HList or similar.

In general more publicly accessible routing would be very nice to have, since at the moment many libraries have to re-implement servant routing, see: Miso.

[saurabhnanda]

Is this related to the following two StackOverflow questions?

• https://stackoverflow.com/questions/41538438/haskell-servant-get-current-route-url-from-handler
• https://stackoverflow.com/questions/55488461/print-all-routes-in-a-haskell-servant-api-definition

[tysonzero]

Not particularly. The first is about servant-server handlers, but my use cases don't involve servant-server, they strictly involve servant-client. The second is also not super related as it's just about pretty printing routes, as opposed to actively routing against them.

[alpmestan]

Right, we do have plans to split out the routing bits. And your suggestions seem like nice things to have indeed! I would definitely be in favour of a patch that adds this.

[tysonzero]

I haven't quite figured out what the best way to implement this would be, exposing the underlying router in a way that is hopefully similar to the way Miso does things definitely seems like an improvement, if only to avoid forcing Miso to re-implement a key part of Servant.

With that said that alone wouldn't make it particularly nice for my use case, which is mainly dealing with routes of a known format (e.g /foo/<fooId>/bar/<barId>/) from third party sites, and either pulling out the varying pieces (e.g fooId and barId) or sending a request to that new route (via Servant as that route would already exist in the Api for that domain).

These kind of situations don't arise with properly designed Api's that work with a proper Schema and use something like JSON, as you aren't going to be returning full URIs, you are going to be returning nice id's which Servant is great at working with. Unfortunately the Api's I am working with are not properly designed nor do they use JSON, which is making me wonder if maybe I should skip the Servant layer, and stick to using Servant for Api's I control, but Servant does have plenty of nice aspects even in these situations.

[chrisdone-artificial]

Related: Run handlers with URI · Issue #1147 · haskell-servant/servant