- why not just extend GET to make a payload not "undefined" anymore? Instead now people have to wonder whether to use GET or QUERY. The non-idempotent methods have at least a difference in semantics, while this here seems mostly another way to provide parameters for essentially the same action.
- QUERY is a somewhat bad name choice, given that URL parameters are also refered to as query string
I wish standards bodies weren't afraid of angering the feet-dragging vendors who haven't had to update their shitty middleboxes in 20 years despite charging their customers through the nose for them. Maybe it would be better for a healthier web if these dinosaur machines got broken once in a while.
I would expect that the majority of all GET requests are non public-facing.
So needlessly breaking all of these machines would have little to no user benefit.
Slightly confusing, I agree. But given that neither are called just "query", and HTTP methods being usually in all caps, I think it won't be as bad. "Query component" (from URIs as specced) VS "QUERY method" should be clear enough.
It’s easier to define semantics for a new method than to expect everyone to change how an existing methods is handled by all existing software.
SEARCH and REPORT, which are probably better names, were already taken by WebDAV, a pre-REST style protocol layered over HTTP that loved (loves?) registering new HTTP methods.
That has always driven me crazy
9 to be precise (RFC 7231 defines GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, RFC 5789 defines PATCH).
Some of those are not commonly used because of various security vulnerabilities that have been discovered over the years (see https://www.kb.cert.org/vuls/id/867593, https://www.kb.cert.org/vuls/id/288308, https://www.kb.cert.org/vuls/id/150227) for some examples.
Some tooling goes as far as defining some of those methods as "forbidden", like what the standard for JavaScript Fetch does.
> 9 to be precise
You are off by 30:
https://www.iana.org/assignments/http-methods/http-methods.x...
Granted, I guess you could argue that because you can use whatever method you want in practice, there is a unlimited set of methods available (depending on how long string whatever server you're using could create, if they are parsing it and so on)