The new method fills the gap between GET and POST, combining the body of POST with the safety and idempotence of GET.
When an HTTP request is too long or complex to be encoded in its URI using GET, developers have long resorted to using the POST method as a workaround. However, this can create issues; while GET requests are defined as safe and idempotent, POST does not necessarily share those characteristics.
To combat the problem, the Internet Engineering Task Force (IETF) has published a proposed standard HTTP request method, QUERY (RFC 10008), which bridges the two functions, taking the best of each.
A safe method is defined as one which is “essentially” read-only, where “the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server,” the IETF standards document states. And when a request is idempotent, no matter how many times it is retried, the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.
POST requests do not always fulfill those criteria. But QUERY requests do. The input to the QUERY operation is, like POST, passed as the content of the request, rather than as part of the request URI as it is with GET. Unlike POST, QUERY allows functions such as caching and automatic retries to operate, precisely because it is safe and idempotent.
Read-only in disguise
“RFC 10008 matters because it gives the web’s favorite workaround a protocol identity,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “Developers have disguised read-only questions as POST commands for two decades; QUERY carries the question in the request body while declaring it safe to retry and cache. The significance is machine-readable intent; retry engines, caches, and autonomous agents act on what a method declares, not on what documentation intends. Under automation, semantics become policy.”
“GET works while a request fits comfortably in a URI, and stops working the moment a developer needs deep filters, long identifier sets or an entire query document,” Gogia explained. “URIs also attract exposure through histories, bookmarks, and access logs, and encoding every input combination into the address quietly turns each permutation into a distinct resource.”
“POST solves the size problem and withholds the promise,” Gogia said. “Its generic semantics admit creation, mutation, and side effect, so no cache, retry engine, or gateway is entitled to assume that a given POST is repeatable or reusable.”
But while QUERY answers the long-running POST-for-search problem, the new method comes with some gotchas. As software engineer Rickvian Aldi noted in a blog post, “The cautious version is: it answers the semantics, not all the deployment work. Front-end code still needs stable query keys. Servers still need validation and cache-control headers. Infrastructure still needs to allow the new method.”
New standards take time
And that will take time; standards are often slow to be adopted. And before QUERY can be widely used, other standards such as the HTML forms standard need updating. That exercise is already in progress by groups such as the Web Hypertext Application Technology Working Group.
“Publishing an RFC as a Proposed Standard doesn’t mean the whole ecosystem supports it the next day,” said open source developer Daniele Teti in a blog post. “It’s the first rung of the IETF standards track: the specification is stable and ready for implementation, but it takes time for browsers, servers, proxies, CDNs, and client libraries to actually adopt it.” No major browsers support QUERY as yet, although, on the server side, Node.js and Go support the method.
Gogia pointed out that the authors of RFC 10008, engineers at Cloudflare, Akamai, and greenbytes, recognize this.
“The retreat route is designed into the standard itself,” Gogia said. “The Location bridge exists so that a QUERY can collapse back into a GET the moment it meets infrastructure that never learned, and the document says as much when it notes that clients can switch to GET for subsequent requests to simplify processing. Read that way, the equivalent resource is less a philosophical concession than a contingency plan, and it is the feature most likely to carry the method through its awkward years.”
