HTTP Just Got a New Method for the First Time in 16 Years: Meet QUERY
If you build or work with APIs, this is the kind of news that doesn't come around often. In June 2026, the Internet Engineering Task Force (IETF) officially published RFC 10008, standardizing a brand-new HTTP method called QUERY. It's the first new standard HTTP method since PATCH arrived back in 2010.
The Problem QUERY Solves
Every developer who's built a REST API knows the drill: GET, POST, PUT, DELETE, PATCH. Each one carries specific meaning. GET retrieves data. It's safe (it doesn't change anything on the server) and idempotent (repeating it produces the same result), which is exactly why browsers, proxies, and CDNs are happy to cache and retry it freely.
But GET has a long-standing weakness: it can't reliably carry a request body, and URLs have practical length limits often just a few kilobytes before a proxy somewhere starts truncating or rejecting the request. That's fine for simple lookups, but modern APIs often need to send complex, structured filters: nested conditions, arrays of categories, price ranges, sort rules, pagination, the kind of payload that turns a URL into an unreadable mess.
So developers did what developers have always done: they cheated. They used POST for read-only searches, because POST happily carries any JSON body you want. It worked but it was a lie to the protocol. POST tells every cache, proxy, and monitoring tool "this changes something," even when it doesn't. That means no automatic caching, and no safe retries if a request times out, because the server has no way of promising nothing was modified.
Enter QUERY
QUERY is designed to take the best of both worlds: the request-body flexibility of POST, combined with the safe, idempotent, cacheable guarantees of GET. A typical request looks like this:
QUERY /products HTTP/1.1
Content-Type: application/json
{
"category": "shoes",
"maxPrice": 100,
"sort": "price_asc"
}
The server processes the filter and returns matching results and because the method is officially safe and idempotent, intermediaries like CDNs and proxies are allowed to cache the response and retry failed requests automatically, the same way they already do for GET.
The spec also introduces some useful mechanics: a Content-Type header is mandatory, so the server knows how to interpret the query (it doesn't have to be JSON, it could be SQL, GraphQL, or a custom format). Servers can advertise supported formats via an Accept-Query header, and clients can probe support ahead of time using OPTIONS or HEAD requests.
RFC 10008 was authored by engineers from Cloudflare and Akamai, among others, a signal that CDN-level and edge support may land faster than most developers expect, since cacheable search endpoints are exactly the kind of traffic those companies want to optimize.
Should You Use It Today?
Not in production just yet. As of mid-2026, QUERY is a finalized specification, but the surrounding ecosystem hasn't caught up. Browsers' fetch() and XMLHttpRequest don't yet have first-class support for sending QUERY requests. Many CDNs and proxies will simply pass an unrecognized method through without applying any of the caching benefits it's designed for. Some frameworks are only just starting to add support, .NET 10 already ships with built-in client and server-side QUERY support.
For security and infrastructure teams, QUERY also means one more method to account for in web application firewalls, method whitelists, and API gateways that were built assuming only the classic verb set existed.
The Takeaway
QUERY won't replace GET or POST overnight, and widespread adoption will take time, that's simply how HTTP evolves. But for APIs built around complex search, analytics dashboards, and report builders, it finally offers a technically honest way to say "I'm just reading, but I need to send you a lot of detail to do it." If you're designing or maintaining APIs, it's worth watching your framework, browser, and CDN provider's release notes over the next year to see when QUERY support lands.