The new HTTP QUERY method explained

ktpsns

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)

koolala

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?

8-prime

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.

tosti

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

doctor_phil

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.

nokeya

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

waweic

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?

grugdev42

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

Rapzid

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.

ramon156

"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

IshKebab

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

_alphageek

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

restful2

This breaks rest/crud.

xxkcd

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

johnnyevert

Will this be compatible with graphql?

mi_lk

OK, but stop trying to make fetch happen.

Asmod4n

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.

haburka

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.

doginasuit

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.