The internet is complex, and you have tons of protocols that are not well supported. TCP/HTTP are well supported by proxies and have well-defined, stable specs, which also help with caching, throttling, etc.

Just because it's old doesn't mean it is worse than alternatives, most likely it is quite the contrary.

WONIBDFI (whether or not it's broke, don't fix it)

a 35+ year old text-based protocol with 3 major variants (two of them supporting binary frames), and which is used to communicate most of the internet

yeah, I also don't get the hype, let's go back to everyone declaring their own communication protocol

If you're doing anything complicated enough to need so much data that it'd be better to send the data in a body, it's probably not a DELETE and so POST would be more appropriate anyway.

DELETE is intended to delete one specific object, pointed to by a unique URL, not to delete arbitrary objects matching some criteria.

DELETE is idempotent, so I am not sure what the body would do?

Right, that process works today just fine, but that's application code that the browser (and middleboxes) can't assume. The idea is that QUERY directly represents that flow to the browser as a direct participant (and to caching middleboxes as well). A QUERY can (optionally) create a search or filter resource and return a Location: response header that points to a GET resource to refresh the next time the same QUERY is asked. The browser can directly cache that Location and associate it with that QUERY body. (So can middleboxes.)

A POST can return Content-Location: to the GET resource, but the browser can't assume that the same POST body contents create the same result Content-Location, whereas the QUERY Location represents the QUERY itself as a repeatable object. (Also, QUERY can return Content-Location instead of or in addition to Location for subtly different caching implications.)

Obviously the approach you mentioned has the downside of two server round-trips being necessary while the QUERY request only requires a single round-trip. Not to mention the two-request approach adds more complexity to both clients and servers, as it mandates that both the client and server have to physically create and manage those resources.

Considering the guideline that QUERY should be idempotent and cacheable, file querying requests come to mind. Reverse image search, for example.

GraphQL implementations could switch to this

I'm curious too. Unless the developer is really passionate about this I don't think a dev will risk (potential) compatibility issues or unexpected footguns to use this when the workarounds do seem to work quite well already. I just dont see the benefit but maybe it's because I am just not aware of a real world use case; happy to be corrected.

We might start using QUERY for the search requests from our web app to our server, if nothing in the stack in between the app and our server side code does not drop the body. A JSON body beats the spaghetti arguments of most filters.

Graphql?

Presumably good GraphQL libraries would support requiring POST for mutation and QUERY as acceptable for all queries that don't involve mutation.

With some post websites (banking) and spa already present.

The only valid argument against HTTP GET with a body is that it has privacy/security risks.

Exist stuff (caches, CDN, etc.) could serve private information because the HTTP GET is cached without checking the request contents. The new standard can avoid this because old stuff does not know about HTTP QUERY.

More complex actually

It won't break GraphQL, as it uses POST. It can very much improve it if adopted: - use QUERY method when querying resources - use POST method for mutations