Quick trivia: before this year, the last time HTTP got a brand-new method was PATCH, back in 2010. That's a 16-year gap. In June 2026, that gap finally closed — the IETF published RFC 10008, officially adding a new method to HTTP: QUERY.
If you've ever needed to send a complex search or filter to an API and had to awkwardly choose between a messy GET URL or a POST that doesn't quite feel right, this method exists because of exactly that problem.
The problem QUERY is solving
For as long as HTTP has existed, reading data with parameters has meant picking between two imperfect options:
- GET is safe, repeatable, and cacheable — but everything has to go in the URL. There's no guaranteed size limit (the spec only recommends a floor of 8000 characters), and complex data like nested filters or JSON just doesn't fit cleanly into a URL string. URLs also get logged far more often than request bodies, which is a real problem if your "search" contains anything sensitive.
- POST can carry a full body, so complex data is easy to send — but nothing about POST tells a cache, proxy, or browser "this is just a read, nothing is changing." POST is treated as unsafe and non-repeatable by default, even when all you're doing is running a search.
QUERY is built to close that exact gap.
What QUERY actually is
Per the RFC itself, QUERY behaves like POST in form — it carries a full request body — but comes with the same reliability guarantees as GET:
| Method | Has a body | Safe | Idempotent | Cacheable |
|---|---|---|---|---|
| GET | No | Yes | Yes | Yes |
| POST | Yes | No | No | Only in specific cases |
| QUERY | Yes | Yes | Yes | Yes |
- Safe means the client isn't asking to change anything on the server.
- Idempotent means sending the same request twice has the same effect as sending it once — safe to retry.
- Cacheable means a response can be reused for an identical request instead of hitting the server again.
Here's why those three properties aren't just theory — a concrete example of what actually breaks without them:
Say your app's network drops mid-request, and your HTTP client automatically retries. If that request was a POST, the client genuinely doesn't know whether the first attempt actually reached the server before the connection dropped. Retry, and you might run the same search twice — harmless for a search, but the exact same mechanism is why "retry on POST" is dangerous for something like a payment. The protocol gives the client no safe way to know it's okay to just try again.
If that same request had been a QUERY, the retry is a non-issue by definition — QUERY is idempotent, so running it twice has to produce the same result as running it once. Your HTTP client, your load balancer, and any proxy in between can all retry it automatically without asking anyone.
The caching angle plays out the same way: a CDN sitting in front of your API can cache a QUERY response and serve it instantly to the next identical request, the same way it already does for GET. It can never safely do that for a POST, because nothing in POST's contract says the response represents a stable, reusable answer.
On the wire, a QUERY request looks like this:
QUERY /products HTTP/1.1
Host: example.com
Content-Type: application/json
{
"category": "shoes",
"price": { "lt": 100 },
"sort": "newest"
}
Same shape as a POST, but the server (and any cache or proxy in between) knows this is a read-only request, not a write.
Where this actually helps
- Complex search and filter endpoints — anything where the query itself is too big or too structured to fit nicely in a URL.
- GraphQL queries — GraphQL reads are already safe and idempotent by design, but sending them as GET often blows past URL length limits. QUERY is a natural fit.
- Anything currently using POST just to work around GET's limits — a pattern that's extremely common, and one that always meant giving up caching and the "safe" guarantee just to send a bigger request.
What's not ready yet
This is a brand-new standard, and it's important to be honest about where adoption actually stands as of mid-2026:
- Browser support is still being evaluated — don't build a public-facing web app around it just yet.
- QUERY is not a CORS-safelisted method, so browser JavaScript calling it across origins needs a preflight request, same as PUT or DELETE.
- Popular frameworks are still catching up — Node.js has supported parsing QUERY since early 2024 (ahead of the RFC itself), and OpenAPI 3.2 already documents it, but Spring hasn't shipped built-in support as of this writing.
- Existing infrastructure is a real concern: WAFs, API gateways, CDNs, and CSRF middleware are often configured around a fixed list of methods — GET, POST, PUT, DELETE, PATCH. Rule sets written before June 2026 may not know QUERY exists, and might reject it, or worse, handle it inconsistently.
- Caching QUERY correctly means the cache key has to include the request body, not just the URL. A cache that gets this wrong opens the door to serving the wrong response to the wrong request.
How a client actually discovers QUERY is supported
You can't just assume every endpoint accepts QUERY — the server has to say so first. It does this with a response header called Accept-Query, usually seen after an OPTIONS request:
OPTIONS /products HTTP/1.1
Host: example.com
HTTP/1.1 204 No Content
Allow: GET, POST, QUERY
Accept-Query: application/json
That Accept-Query: application/json line is the server telling any client: "yes, you can QUERY this endpoint, and send the body as JSON." Without it, a client has no reliable way to know whether QUERY will even be understood here — which is exactly why the gradual rollout (advertise it, then let clients adopt it) depends on this header existing in the first place.
How to actually roll this out
The sane path, based on what the RFC's authors themselves suggest, is gradual:
- Keep your existing POST-based search endpoint working exactly as it is.
- Add QUERY as a second way to reach the same endpoint.
- Advertise support using the
Accept-Queryheader, so clients can detect it. - Let clients migrate over to QUERY on their own timeline, instead of forcing a switch.
Nobody needs to rip out a working POST search endpoint tomorrow. This is a "start advertising it, let adoption happen naturally" kind of rollout, not a "migrate everything this sprint" one.
The one-line version
HTTP just got its first new method in 16 years. QUERY gives you a way to send a complex, structured request body — like POST — while keeping the safe, repeatable, cacheable guarantees of GET. It's real, it's an official standard, and it's genuinely useful — but browsers, frameworks, and infrastructure are all still catching up, so treat it as something to watch and start testing with, not something to depend on in production just yet.
Have you run into the "GET can't hold this much data, but POST doesn't feel safe to cache" problem yourself? That's exactly the itch QUERY is trying to scratch.
Top comments (0)