Using GET with a Body doesn't work if you try using it in the browser with JS fetch for example[1]. Additionally, a lot of existing web servers by default ignore GET requests with a body.

The use case of QUERY is because POST conveys non-safe, non-idempotent requests which can potentially modify stuff according to the REST spec. GET requests on the other hand convey retrieval of a resource. However, due to GET requests not having a body, there's a limit to the amount of data you can put in the URL and you also cannot put sensitive data in it.

Additionally, GET requests are meant to be highly cacheable by default while a lot of the QUERY type requests are usually meant more for one-shot access.

QUERY is meant to address these limitations.

[1]: https://github.com/whatwg/fetch/issues/551

I’ve seen a framework strip body content off GET requests, so doing hacky things doesn’t even always work. The QUERY method is a welcome addition

The whole stack is a pile of badly designed hacks. Not much point in fixing it now. I mean they can’t even spell referrer correctly.

  > Just because it works, doesn't mean its the right way

405 Method Not Allowed is trivial to fall back to POST. How do you know the GET request behaved incorrectly?

Yeah, query seems just GET with a body. No difference in protocol nor behavior

zero. Many libs will/can just request method as a string so you can start coding now

> I've had my fair share of situations where I wished for something like HTTP QUERY.

Using POST instead comes with no drawbacks

I can implement it in about 10 minutes. Not even kidding.

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.

A absolute swats of middle boxes that will not get addressed ever. As industry, it's preferable to create something that is a hard break and makes players upgrade and give people a feature to argue for said upgrade

We might start using QUERY for the search requests from our web app to our server, if nothing in the stack in between the app and our server side code does not drop the body. A JSON body beats the spaghetti arguments of most filters.

Considering the guideline that QUERY should be idempotent and cacheable, file querying requests come to mind. Reverse image search, for example.

GraphQL implementations could switch to this

I'm curious too. Unless the developer is really passionate about this I don't think a dev will risk (potential) compatibility issues or unexpected footguns to use this when the workarounds do seem to work quite well already. I just dont see the benefit but maybe it's because I am just not aware of a real world use case; happy to be corrected.

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 [..]

Yeah I always disliked that there's this idea that you can't put a body on a GET request. Iirc openapi generators goes out of its way to not support that which has lead to me writing a small rant into an API specification before to explain why the get_xyz uses POST...

semantics become extremely relevant when "proxies" start caching.

Is it not just READ? As for rest, why?

How so?

More complex actually

Arguably the only explanation you need is that "QUERY is the same as GET plus a body". The article just explains what GET is and isn't, but that can be implied.

The article describes the current situation first. The whole explanation is quite simple: QUERY requests are the same as GET, but they have a body.

It doesn't really need that much explanation though. TL;DR: It's GET but with bodies officially supported.