ReqBody-like GET param parsing

[phunehehe]

ReqBody is great, it captures the whole POST body and make it available in a type. I wonder if it's intended that the same thing isn't available with GET. It would be nice if I can have a GET param that is a URL encoded JSON string converted into a type just like that. I would have used POST, but that has a vague effect on caching. Any thoughts?

[alpmestan]

I'm not sure query string parameters are supposed to be in a particular format. We use FromText because each query string param's value is a bare ByteString/Text. We technically could allow content types there too instead, but I'm afraid it might confuse people (because you usually don't send any JSON or HTML or ... in your query string parameters). Thoughts?

[thsutton]

I'd prefer wrapper types:

data JSONFromText a = JFT a

instance FromJSON a => FromText (JSONFromText a) where
...

And then use

QueryParam "customer" (JSONFromText Customer)

On 17 Apr 2015, at 1:29, Alp Mestanogullari [email protected] wrote:

I'm not sure query string parameters are supposed to be in a particular format. We use FromText because each query string param's value is a bare ByteString/Text. We technically could allow content types there too instead, but I'm afraid it might confuse people (because you usually don't send any JSON or HTML or ... in your query string parameters). Thoughts?

―
Reply to this email directly or view it on GitHub.

[phunehehe]

I'm not sure query string parameters are supposed to be in a particular format.

I agree that it might be confusing, but to be fair, the POST body isn't supposed to be in a particular format either. jQuery, for example, treats get and post data in the same way.

In fact, it was a little confusing to me in the beginning, that I have to JSON.stringify the POST data when making requests. I take it that we want to make use of Haskell's type facilities, and I like that. And, if we use types with POST, why not do the same for GET?

Unless feature creep is a problem (in which case @thsutton's solution is workable), we could have another type (QueryBody?) that works the same way as ReqBody.

[alpmestan]

Re. GET and request bodies: because GET requests usually don't take a request body as argument. I remember reading this a couple of months ago. Query string parameters do however fit your bill.

Relatedly, you can easily go from a javascript object to the corresponding query string using jQuery's param.

I don't really feel comfortable encoding things as JSON in the query string (at least in the main servant package), the URLs would be quite horrible to read and good old query params are the actual recommended solution for this (with one param per "field in the object").

If you want to use your suggestion, you could indeed use @thsutton's trick, but I'm not sure we should provide it out of the box in the servant packages -- unless @jkarni has a different opinion?

[jkarni]

I like the idea, and think we need to support this at some point. It shouldn't be hard - just another QueryParam-like argument - though there are nuances. We have to think about how the new combinator would interface with the old ones, for example. And whether we want to subsume the decoding class under the existing FormUrlEncoded.

[fishtreesugar]

It looks like QueryParamForm mentioned in #728 #729 #1047

[alpmestan]

Yes.