Add endpoint factories for custom parsers

[Tenor]

Currently we have endpoint creators like single, singleBy and singleRead. The only way to write a custom parser is through singleRead and many libraries assume Read and Show instances are meant for developer-readable representations (exa. Data.UUID, ByteString, UTCTime) as well as using Read is just plain annoying.

Can we add an additional endpoint creator category like (String -> Maybe sid) -> Endpoint sid mid aid or Parser sid -> Endpoint sid mid aid for some assumed parser library (exa. attoparsec)?

[Tenor]

My current need is because I'm using UUIDs as resource identifiers and the current Data.UUID library only reads stringified UUIDs since it assumes Show and Read should serialize and parse valid Haskell expressions. So I need to write a custom Read instance for my newtypes.

[Erik Hesselink]

There's definitely an opportunity to push more of this into rest, but I think there are at least two ways you can implement this with rest today:

1. You can use singleBy to return a Maybe UUID. Then in your handler you can throw an error on Nothing, copying what rest does (I think it throws IdentError (ParseError "some message")).
2. You can wrap your UUID in a newtype, and write a custom Read instance.

Changing this in rest would mean changing the Rest.Dictionary.Types.Ident type. We can probably write something more general that also covers the two current cases there.

[Adam Bergmark]

Overall I'd like to see all conversions be of the form i -> Either e a. For the function in question you would then have String -> Either e a where e ~ String currently, but in the future it could be any type that can be converted to the error output type of the handler.