A couple of quick observations and comments after skimming through this (some of these are mentioned or hinted at in the RFC).

With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY.

One of the advantages of GET is the direct visibility, which makes modifications simple and easy for almost anyone (end users, testers, etc.).

The larger question I have is who will choose to adopt it sooner, with web servers, web application frameworks and web browsers in the mix.

▲

arp242 4 hours ago | parent [-]

The situations where I've wished for GET to be able to have a (typically JSON) body were all in situations where the request isn't "user visible" in the first place. That is: API calls, SPA apps, ajax requests, that sort of thing. Not something people are really supposed to bookmark or call directly.

If today you're doing some JS-fu to make an ajax GET request then you already need to do something to have permalinks (if desired).

Completely worth bringing up and thinking about, but unless I'm missing something I don't think a QUERY verb will change all that much here?

▲

flakes 2 hours ago | parent [-]

> unless I'm missing something I don't think a QUERY verb will change all that much here?

The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.

Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.

	▲	badbotty 25 minutes ago \| parent [-]
		I like the safety aspect of QUERY. Having CDNs cache based off the semantics of the content might be a hard ask. I wonder if this might lead to a standards based query language being designed and a push for CDNs to support it. Otherwise you probably need to implement your own edge processing of the request and cache handling for any content type you care to handle.