Will this be compatible with graphql?
It won't break GraphQL, as it uses POST. It can very much improve it if adopted:
- use QUERY method when querying resources
- use POST method for mutations
The new HTTP QUERY method explained
131–140 of 179 posts
Re: The new HTTP QUERY method explained
#132This breaks rest/crud.
How does this break rest?
Re: The new HTTP QUERY method explained
#133If it needs so much explanation and discussion, maybe it is not a great idea after all?
I don't think this requires so much discussion; it is a very obvious and simple addition, IMO.
Re: The new HTTP QUERY method explained
#134Earlier quoted context omitted.
It sounds like GET with a body is just undefined behavior. Why not just standardize it? It seems to be a better way than adding a new method.
A lot of un-updateable software out there that strip the body. Especially when the companies behind it doesn't provide support anymore.
will those support QUERY?
Re: The new HTTP QUERY method explained
#135Earlier quoted context omitted.
Proxies are allowed to drop bodies of HTTP GET requests. RFC 9110 states: > [..] content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request [..] > A client SHOULD NOT generate content in a GET request [..]
> ... unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. You left out the important part.
How does the origin server indicate that?
Re: The new HTTP QUERY method explained
#136"QUERY is just GET" "Using GET with a Body works" Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense. Just because it works, doesn't mean its the right way
So a POST with explicit caching semantics?
Re: The new HTTP QUERY method explained
#137I wish there was an HTTP method that directly signals async intent of the server. I know we have 202 Accepted status, but these days there are so many APIs that use the async patterns and each one differs a bit. Having a standard for accepting async jobs with idempotency and notification about results via webhook
Re: The new HTTP QUERY method explained
#138Earlier quoted context omitted.
> "Using GET with a Body works" Except it doesn't. Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded. It sounds like most people with the "just use GET" nonsense are far from having any experience in cloud computing.
QUERY won't be supported by them either. So, change is required. Just change GET to allow for body and move on. Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is. QUERY will likely need firmware updates, core engine updates, etc. Meanwhile, tweaking GET is a rule change.
Yeah I really don't understand the anti-GET-body argument.
"Using GET with a body isn't in the spec, WAFs and webservers that haven't been updated might reject it!"
Ok, QUERY wasn't in the spec when those were written either. What do you expect those appliances to do with a totally unknown verb?
It's a welcome addition but the new method is pure marketing. There's no reason the update couldn't have been to expand GET instead of add support for QUERY.
Re: The new HTTP QUERY method explained
#139>> QUERY request can be cached I have a weird feeling. Query body is encrypted by https. So CDN will not be able to cache results. In order to make it work right - whole topology of the internet should be redone. Caching on the backend server will not give any real gains for large scale apps.
The whole connection is encrypted by https, the request body is treated the same as the url, the headers or the response. The only unencrypted parts are the IP addresses/ports and the domain name (if SNI without ECH is used). CDNs already terminate TLS connections so they can cache GET requests.
[flagged]
Re: The new HTTP QUERY method explained
#140Earlier quoted context omitted.
The whole connection is encrypted by https, the request body is treated the same as the url, the headers or the response. The only unencrypted parts are the IP addresses/ports and the domain name (if SNI without ECH is used). CDNs already terminate TLS connections so they can cache GET requests.
Even past the TLS point (CDNs terminate TLS, so they can read the body) there's a harder problem nobody's solved: to cache a QUERY the cache has to fold the body into the cache key, and there's no standard way to canonicalize a request body. {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries; whitespace, float formatting, unordered keys all fork the key. GET gets this for free because…
> {"a":1,"b":2} and {"b":2,"a":1} are the same query and two different cache entries
These two payloads are actually different. You're talking about semantics, which is determined by the payload format; in the case of JSON, these two are semantically similar.
> GET gets this for free because the URL is already a normalized string
It's the same principle; the order of properties matters too.