HTTP Finally Has a Method for Complex Reads: Meet QUERY

Every backend dev has hit this wall. You've got a search endpoint. It started clean, then someone added filters, then sort keys, then pagination cursors, and now there's a JSON object base64-encoded and stuffed into a query parameter because the framework wouldn't let you do anything else. And somewhere between your client and your server, a proxy has decided your URL is too long and quietly handed back a 414.

For years there were two ways out, and both were compromises. GET is safe, idempotent and cacheable, but the query lives in the URL, and URL length limits vary across proxies that never agreed on a number. Those URLs also land in access logs, which is a bad place for a filter object that might carry something sensitive. POST takes a big body fine, but nothing in the protocol says the operation is read-only, so caches treat it as a write and you lose caching entirely.

In June 2026 the IETF published RFC 10008, and it closes exactly this gap. It defines a new HTTP method: QUERY.

It's part of a broader moment where the protocol layer is catching up to how developers actually build. We wrote about a parallel shift in how the Model Context Protocol is changing what software needs to expose to AI agents. Same principle, different layer: when enough developers build the same workaround, that's usually a signal the spec needs a standard.

What QUERY actually is

QUERY is safe and idempotent like GET, but it carries a request body like POST. That one sentence is the whole idea. You send your filter object, your GraphQL-ish query, your SQL-ish expression or whatever your API speaks, in the request body. The server processes it and responds with the result. Because the method is declared safe, intermediaries know the client isn't asking to change anything, so they can cache and retry without second-guessing you.

The spec was written by Julian Reschke, James Snell and Mike Bishop under the HTTP Working Group, and it's out as a Proposed Standard. The name has a small backstory worth knowing: an earlier draft called it SEARCH, and there were existing safe-with-body methods like PROPFIND and REPORT the authors could have reused. They settled on QUERY partly because it maps cleanly onto the URI's query component, and partly because the older options came out of WebDAV, which not everyone remembers fondly.

The details that'll bite you

A few things are worth reading twice before you ship anything.

Caching works, but the cache key has to include the request body, not just the URL. Two QUERY requests to the same path with different bodies are two different requests. If your cache hashes or normalises that body wrong, you've opened the door to cache poisoning. This isn't a header you set once and forget.

QUERY isn't on the CORS safelist either. Browser JavaScript firing a QUERY request triggers a preflight, same as any non-simple method. Nothing exotic, but don't be surprised when the OPTIONS call shows up in your network tab.

The spec also adds an Accept-Query response header, which lets a server advertise the query formats it accepts, and it defines sensible behaviour for a 303 See Other response, so a query can be redirected to a plain GET on another URI when that makes sense.

The honest bit

This is a Proposed Standard, not a finished, universally supported reality. Your WAF might not recognise the method. Your API gateway, load balancer or CSRF middleware might run an allowlist written before June 2026 that only knows GET, POST, PUT, PATCH and DELETE. Some of those will reject QUERY outright; others will route or inspect it differently to POST, which is its own special kind of debugging afternoon. Framework and client support is still catching up as well.

So no, I wouldn't tear out working POST endpoints this quarter. But the direction is right. QUERY is the method a lot of us have quietly needed for a decade, and now it has an RFC number instead of a workaround. If you're designing a new read-heavy API, it's worth reaching for.

If you'd like a second opinion on the API layer before you commit to an approach, we do backend architecture and custom software development.