The new HTTP QUERY method explained (opens in new tab)

"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

Slightly off topic Funfact: you can buy a several thousand dollars expensive ssl intercepting proxy appliance which doesn’t support anything beyond http/1.1.

Will be fun when those see a whole new http verb, I bet that leads to at least DoS by the track record of that company.

HTTP QUERY was discussed many times in the past here:

https://news.ycombinator.com/item?id=48568502 (4d ago, 173 comments)

https://news.ycombinator.com/item?id=29794838 (4y ago, 125 comments)

I 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

> using HTTP GET with a request body is a bad idea, as for example users behind a corporate firewall or a different browser may be unable to use your website.

So is using QUERY requests for quite some time from now.

I wonder what the drawbacks of standardizing a GET body would have been. CoAP already has it (which creates friction in building CoAP<->HTTP proxies).

All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?

It blows my mind that people are invested in this. HTTP is a 35+ year old text-based protocol. Its becoming the COBOL of digital transmission.

Just as one example, among many, you could try WebSockets (or some other similar protocol) and then push anything over it. Your message could be plain text, JSON, binary, whatever. Web Sockets and protobufs are bidirectional (full duplex) too.

Would this be a defensible decision if the spec were designed today, an additional read method that takes the same argument, entirely for the purpose of not ignoring a specific property? It seems like just the path of least resistance considering all the controversy and legacy tools. That is not a good way to maintain the functionality and long-term relevance of a spec. But if there is a good reason to design it this way from the beginning, I'm curious to know more.

It's interesting to see additions to HTTP methods as it much feels like the existing ones are set in stone. At least for the time that I have been a developer. I'm curious to see how fast the adoption/support for HTTP QUERY will be. I've had my fair share of situations where I wished for something like HTTP QUERY.

The other issue with adding a separate supported way to do what people did with GET+body is that we will probably see servers slowly drop support for the GET+body approach when QUERY gets widespread support/usage, and then a ton of other stuff will break.

Unless you're really going to improve things or the existing practices are really too painful, standards should follow convention. Even though GET+body is not handled the same everywhere, it's easier to make that the standard than it is to make a new syntax the standard.

OK, but stop trying to make fetch happen.

I still don't get the need for QUERY. One can create a search or filter resource with a POST request and then query it using GET. As a bonus, creating a resource allows it to be shared and cached.

Good use case for graphQL requests which use POST for all queries? But then again what about mutations

Nice, not having bodies on GET has been a pet peeve of mine for a long time. It would be nice to allow bodies on DELETE as well, but that is less of a problem in most cases.

This is awesome and very much needed. Sending massive get requests always felt like shit and support for body parsing of GET was all over the place. I hope it will be adopted quickly.

What do you think people will make the Query request body? Most everything will use this for JSON but it could be anything so what other interesting things do you think will go in there? Query 1 + 1 and get 2?

What are the chances sites start using this to prevent sharing links...

This looks like a effort to inject some planned obsolescence in HTTP more than anything else.

Will this be compatible with graphql?

We should have just added optional body support for GET requests.

So much simpler...

This breaks rest/crud.

Don’t add new stuff (query). Instead fix the broken shit that’s already added (get). Sigh. Xkcd standards.

nice man

If it needs so much explanation and discussion, maybe it is not a great idea after all?

Body is already optional with GET. Proxies aren't supposed to touch it or assign meaning to it; it's between the client and the end server.

A whole new method whose semantics don't really fit with the others is.. An odd way forward.

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