The main focus of HTTP 2 and 3 was apparently performance, and hardly any of the other fundamental issues of the protocol. It's nice to see that some work is put into something like QUERY as well, which improves HTTP as an API protocol (REST) - although the motivation appears to be performance again and I always have mixed feelings when I see the term "idempotent" in a context that likely involves database systems. Too often, such requests do have side effects of some kind and preventing request retries throughout the stack isn't easy.
Definitely not performance, QUERY is an improvement/hackfix. Browsers have a cap on size of the request headline path (used to be very small for IE7), and server software also tend to cap the size of it, as a security mitigation (smth like max header size, similar to what happens with cookies). For this reason, technologies such as elasticsearch or graphql, which allow for quite large query defs, use POST and fit the query in the body instead, which is not bound to the same limitations.
Semantically, such queries are cacheable, but the request being POST, intermediate edge proxies or CDNs won't cache the request. This means clients pay the penalty every single time. Moreover, browsers can't have url-based history with such solutions, as POST requests can't "go back".
So QUERY fixes this. Semantically. Now you have to build support in middle boxes for it, and browsers must support it as well.
As far as I know, GET and DELETE requests support a payload body as per one of the later specs, whereas an earlier version wasn't fully clear on this and people assumed it's forbidden. Unfortunately, there's still a lot of software conforming to the interpretation of the old spec, which means you cannot count on these HTTP verbs to be supported.
Given this legacy, QUERY seems like an adequate solution. However, it seems to me like it's only intended for read queries. Write queries are generally not cacheable semantically, at least not in my world. Was the naming influenced by GraphQL by any chance, which distinguishes between queries (read) and mutations (write)?
The practical effect that my coworkers keep telling me about is that the client or an intermediary like a load balancer may retry the same request until it is successful, with the expectation that the resource (records or settings in a database system in our case) is only modified once. A database query that does something like value = OLD.value + 1 cannot be safely retried. There are circumstances under which the outcome of a transaction can be unknown but it might still succeed, and the client should be prevented from doing accidental changes. With read queries this should be rare, but even then there can be side-effects affecting the overall system state. There are of course solutions to this for the application side, like the usage of idempotency keys.
