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

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

no matter which verb you end up coding for

@ordnungswidrig: is this correct?

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.

https://tools.ietf.org/html/rfc7231#section-4.3.1

what about HTTP 1.1 ?

(sorry, didn't read properly)

HTTP/1.1 does not allow it IIRC.

You're quoting HTTP 1.1 there

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.

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

I quoted that from rfc7231

'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

rfc 7231 is HTTP 1.1, not HTTP 2

Oh, I’m sorry, I got confused.

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

I wonder if any http client lib supports that

And what proxies will do to your query

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

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

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

brilliant

you also get free query storage, ala pastebin that way

well, kinda

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

and requires 2 hops

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

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

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

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