[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

[EnnEmmEss]

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

[nesarkvechnep]

There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.

[jefc1111]

Yep. We had to change our app when we took on a client with a strictly configured WAF which rejected GET with body. I know I have come across multiple points where I have used POST when I know it is wrong, or GET with a body, when I know it is wrong. So I welcome QUERY!

[entuno]

AWS CloudFront blocks GET requests with a body, so it doesn't even have to be a particularly strict setup or an explicit WAF.

[ronbenton]

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

[pdpi]

Insofar as I'm concerned, a GET request with a body is an attack-shaped aberration. E.g. Somebody who's trying to get me to mix up validating query string parameters and request body parameters.

Hacky things not working is a feature, not a bug.

[tgv]

I'd say it's the framework doing the hacky thing. It should be optional. AFAIK, the HTTP spec allows for it, under certain conditions. "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."

[psychoslave]

Is the stripper service in question already implementing it?

[Bombthecat]

Some security/ API gateway block requests when it's a GET with a body.

[dotancohen]

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

Tell that to anybody in the business long enough to decipher someone else's Perl!

[nixon_why69]

It's possible that the slogan "There's one obvious way to do it" as a riposte to "There's more than one way to do it" was more responsible for Python's first wave of success than anything else.

[maxloh]

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.

[Vosporos]

A lot of un-updateable software out there that strip the body. Especially when the companies behind it doesn't provide support anymore.

[earthdeity]

will those support QUERY?

[bellowsgulch]

So a POST with explicit caching semantics?

[cryo32]

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.

[stymaar]

You're missing the point. Using GET with a body is currently unspecified, so of course you're not supposed to do it (though you're not forbidden to either).

But specifying this behavior would get you in the same situation as adding a new method: everything not up to date with the spec will keep behaving poorly but newer system would work.

The only benefit of adding a new method is for marketing/awareness: it may end up getting support faster than the alternative because it sounds as a sexy new thing to implement. This kind of benefit should not be overlooked, but we should also acknowledge its limits: most of enterprise stuff (WAF, frameworks, etc.) are not going to work overnight just because it's a new method instead of a spec change.

[locknitpicker]

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

[topham]

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.

[akersten]

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.