Add support for query string and url parameters?

[inputusernamehere]

What are you thoughts on adding options to allow the user to choose how parameters are transmitted? Similarly it would be nice to be able to control the encoding of request bodies. For example if we want to look up an Article by its id, we could do that in (at least) three different ways:

1. POST /articles, and include the id in the body as json, xml, etc.
2. POST /articles/{id}, including the id directly in the URL
3. POST /articles?id={id}, including the id in the query string

Right now Fable.Remoting is the quickest and easiest way to make APIs if you control both ends of the API. But doing this would allow us to use Fable.Remoting even if we only control the backend, or if we only control the frontend, and we need to match an existing API spec.

I'm not sure what the API of this library would look like with these extra features, since ideally each endpoint/proxy would be able to use all these different options at once. For example my endpoint could look like POST /articles/{id}/comments?sortOn=timestamp&sortDirection=descending, and also have additional data in the request body.

I understand that this would be a lot of extra options to add to the library, and that it might make it less easy to use. But maybe there is a way to keep the ease of use and add this kind of flexibility?

[Numpsy]

Would this be moving more into Hawaii teritory? (as in, the OpenApi stuff already deals with different ways of passing parameters and such)

[inputusernamehere]

The most attractive feature that Fable.Remoting has, to me, is a shared understanding of the API spec between the frontend and the backend. Also because it does not use code generation, it's very easy to evolve the spec as you go. So not quite the same as Hawaii (although I'm glad you made me aware of it as I might have a use for it elsewhere).

I think my suggestion (or question really) is probably out of scope for Fable.Remoting. It's probably more suited for a different (future) library, so feel free to close this issue. I've been sticking with regular saturn/giraffe HttpHandlers since it has the flexibility I need, even though it's not quite as silky smooth as the Fable.Remoting way.

[Zaid-Ajaj]

Hi there @inputusernamehere, I understand where this idea comes from but really it is out of the scope of Fable.Remoting. The library is made with the idea that it will "Just Work" with defaults when having F# both client and server. If you only control the server, then I would indeed go with plain old HttpHandlers.

There are some Giraffe extensions I've built that might help with your use-case:

• https://github.com/Zaid-Ajaj/Giraffe.QueryReader (for easily binding query string parameters)
• https://github.com/Zaid-Ajaj/Giraffe.JsonTherapy (for easily binding simple JSON from request bodies)
• https://github.com/Zaid-Ajaj/Giraffe.GoodRead (for easily working with DI)

Hope this helps