For basically our entire careers as developers, HTTP has shipped with the same small set of verbs. GET fetches data, POST sends or creates it, PUT replaces a resource, and DELETE removes one. We learn them early, we lean on them daily, and we rarely stop to think about them. That is exactly why it stands out that a new one arrived in June 2026. That month the IETF published RFC 10008 and made QUERY an official part of HTTP, the first brand new method to reach that stage in roughly sixteen years, since PATCH back in 2010. What started life as a long running proposal inside the HTTP Working Group is now a real, standardized method. The obvious question is: why did we need it?

The problem: searching with complex filters

To understand that, think about the most ordinary thing an API does: search. Almost every REST API grows a search or filtering endpoint sooner or later, and those endpoints need to accept a lot. Sorting rules, pagination cursors, date ranges, arrays of IDs, nested conditions, sometimes a full structured filter object. The question that QUERY answers is deceptively simple. How do you send all of that to a server in a way that is both correct and practical?

The instinctive answer is GET, because reading data is exactly what GET is for. The trouble is that GET carries its parameters in the URL, and URLs were never meant to hold complex data. There is no reliable maximum length you can count on, because a request can pass through browsers, proxies, load balancers and CDNs that each set their own limit. Encoding nested or structured filters into a URL safe string is awkward and ugly. Worse, URLs leak. They end up in server logs, in browser history and in bookmarks, which is a real problem the moment your query contains anything sensitive. And there is a subtle caching issue too: the same question asked with the parameters in a different order looks like a completely different resource, so your cache treats them as unrelated.

The POST workaround and its quiet lie

So developers reach for the other option: POST. POST happily carries a body, so a POST /search endpoint can accept any filter object you like. It works, and we have all done it for years. But there is a quiet lie hidden in that approach. POST is not safe and it is not idempotent. It tells every piece of infrastructure along the way to assume the worst, that something might be created or changed. Caches will not store the response, because they cannot know the request was read only. Automatic retries become risky, because if a connection drops mid request, nobody can be sure whether state changed on the server. And no proxy or gateway can tell, just by looking, that this POST was only ever asking a question.

What QUERY does

This is the gap QUERY was designed to fill. It borrows the request body from POST and the safe, idempotent semantics from GET, and combines them into a single method. A QUERY request identifies the target resource with the URI, just like GET, but it carries the actual query in the request body, just like POST. Because the method is explicitly safe and idempotent, every intermediary now knows the request only reads data and can be repeated without side effects. On the wire it looks almost exactly like a POST, except the verb up front is QUERY, and that one word changes how the whole system is allowed to treat it.

Caching and smart headers

That safety unlocks something POST could never offer for searches: caching. QUERY responses can be cached, but with an important twist. The cache key is built from both the URL and the request body, not the URL alone. That means two QUERY requests to the same endpoint with different bodies are correctly treated as different queries, which is exactly what you want. The spec also adds a few thoughtful details around this. A new Accept-Query header lets a server advertise which query formats it understands, and a response can point back at a result with Content-Location, or at the query itself with Location, so a client can re-fetch a result or re-run a query later without resending the whole body.

Can you use QUERY today?

The honest question for any working developer is whether you can actually use this today, and the answer is the usual mix of yes and not yet. On the server side things are surprisingly ready. Node.js has parsed QUERY as a method since early 2024, and languages like Go and Rust treat HTTP methods as plain strings, so you can route QUERY requests right now with nothing more than the standard library. OpenAPI can already document QUERY endpoints, and frameworks like Spring and ASP.NET Core have support in progress. The slower part of the story is the browser and everything between it and your server. The fetch API, proxies, WAFs and corporate firewalls with strict method allowlists will all need time to catch up, and because QUERY is not on the CORS safelist, cross origin requests trigger a preflight. None of that is a flaw in the method itself, it is simply the reality of how long infrastructure takes to move.

Adopt it gradually, without breaking anything

For that reason the sensible way to adopt QUERY is gradually rather than all at once. You can add a QUERY handler alongside your existing POST /search endpoint, advertise it with Accept-Query, and let clients migrate as their tooling starts to support it. Nothing breaks, and you get the cleaner semantics and caching benefits wherever the whole path already understands the method. HTTP does not change often, which is exactly why it is worth noticing when it does. QUERY is a small addition on paper, but it finally lets a request say what it actually means, and for anyone who builds or consumes APIs, that honesty is long overdue.