Fork me on GitHub
#yada
<
2015-07-02
>
malcolmsparks13:07:24

GETs can have request bodies right? So the graphql, datomic pull-api or whatever you're using can be send as a request body, rather than as a query parameter

malcolmsparks13:07:43

yada allows for that - you can have forms, bodies, headers as well as path and query parameters

malcolmsparks13:07:50

no matter which verb you end up coding for

ordnungswidrig13:07:49

no quite. HTTP/2 allows body for GET requests but it’s not defined: > A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

malcolmsparks13:07:17

what about HTTP 1.1 ?

malcolmsparks13:07:34

(sorry, didn't read properly)

ordnungswidrig13:07:48

HTTP/1.1 does not allow it IIRC.

malcolmsparks13:07:21

You're quoting HTTP 1.1 there

malcolmsparks13:07:21

A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

malcolmsparks13:07:35

that seems to me to mean you can send Graph queries in request bodies

ordnungswidrig13:07:03

I quoted that from rfc7231

malcolmsparks13:07:04

'existing implementations' may not allow it, but it's not a problem - we're not going for interop here, just a way fo composing a 'big' query via a GET

malcolmsparks13:07:15

rfc 7231 is HTTP 1.1, not HTTP 2

ordnungswidrig13:07:31

Oh, I’m sorry, I got confused.

malcolmsparks13:07:43

seems reasonable to me to say that request bodies can be used for graphql-like queries

ordnungswidrig13:07:57

I wonder if any http client lib supports that

ordnungswidrig13:07:08

And what proxies will do to your query

malcolmsparks13:07:24

I'm not sure that proxies will fail, they probably won't cache based on the body though

malcolmsparks13:07:35

but you could hash the body and use that in a query parameter... 😉

ordnungswidrig13:07:31

that’s what I suggested with POST: POST query to /search get redirect to /search/hash-of-the-query to receive the results

malcolmsparks13:07:47

you also get free query storage, ala pastebin that way

malcolmsparks13:07:54

but it seems like a hack, insofar as it's not really a POST but a GET

malcolmsparks13:07:11

and requires 2 hops

malcolmsparks13:07:46

that's one hop too many, especially for the graphql folks who already think REST is too chatty

ordnungswidrig13:07:57

This workaround was just for the case the your in an environment where POST request would not be cached properly.

ordnungswidrig13:07:32

I guess we can rely on that nowadays. Browsers and caching proxies get caching and conditional execution of POST responses right.

ordnungswidrig13:07:59

The only thing is you need to make use of the if-none-match header, which allows the server to respond to a POST with 304 not modified