"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 2 hours ago | parent | next [-]

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

▲ jefc1111 31 minutes ago | parent | prev | next [-]

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!

▲ maxloh 8 minutes ago | parent | prev | next [-]

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.

▲ ronbenton 2 hours ago | parent | prev | next [-]

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 2 hours ago \| parent \| next [-]
		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 an hour ago \| parent \| prev \| next [-]
		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 2 hours ago \| parent \| prev [-]
		Is the stripper service in question already implementing it?

▲ cryo32 2 hours ago | parent | prev | next [-]

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.

▲ dotancohen 2 hours ago | parent | prev | next [-]

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

▲ Bombthecat an hour ago | parent | prev | next [-]

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

▲ locknitpicker an hour ago | parent | prev [-]

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