HTTP Just Got Its First New Method in 16 Years — Meet QUERY

HTTP Just Got Its First New Method in 16 Years — Meet QUERY

For almost three decades, every backend developer has worked within the same limited toolkit: GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS. We've built entire architectures, caching layers, and security tools around these seven methods. That changed this year.

In June 2026, the IETF officially standardized a new HTTP method: QUERY, published as RFC 10008. It's the first genuinely new HTTP method since PATCH landed as RFC 5789 in March 2010 — a 16-year gap. The RFC was authored by engineers at greenbytes, Cloudflare, and Akamai, and went through the full IETF Standards Track process. eCorpITeCorpIT

The Problem QUERY Was Built to Solve

Every backend developer has hit the same wall: how do you send a complex, structured read request?

Option 1: GET. Semantically correct — safe, idempotent, cacheable. But everything has to live in the URL. That breaks down fast:

1. No one knows the real size limit ahead of time, because the request passes through several uncoordinated intermediaries
2. Complex filter objects turn into unreadable, error-prone query strings
3. Sensitive data in a URL is far more likely to get logged than data in a body

Option 2: POST. Solves the body problem, but at a cost — nothing in the protocol tells intermediaries the operation is actually read-only. Caches and proxies have to treat it as unsafe and non-retryable by default, even when all it's doing is fetching data.

For years, developers have "faked" safety by using POST for search — telling HTTP the request might change something, when it never did.

What RFC 10008 Actually Defines

QUERY requests that the target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. In practice, that means: IETF

1. Safe — no server state change
2. Idempotent — repeating the request is guaranteed to be safe, enabling automatic retries
3. Cacheable — responses can be cached the same way GET responses are
4. Has a request body — designed for structured, potentially large payloads from day one
5. A distinct semantic — separate from POST, so intermediaries can finally treat it correctly

Early drafts of the spec actually used the name "SEARCH," borrowing from WebDAV conventions, before the working group settled on "QUERY" — a more generic name that better reflects a general-purpose, read-only operation rather than a search-specific one.

The Part Most Coverage Is Missing: Infrastructure Isn't Ready

This is where teams need to slow down before jumping in.

1. Older WAF, proxy, framework, and load-balancer policies may not recognize QUERY yet. Some stacks will reject it outright; others may route or inspect it differently than POST. Hive Security
2. QUERY is explicitly cacheable, and the cache key must include the request body — caches that hash or normalize that body incorrectly open the door to cache poisoning and cache deception. Hive Security
3. QUERY is not a CORS-safelisted method, so browser JavaScript has to trigger a preflight request before using it. Hive Security

On the ecosystem side: Node.js has parsed QUERY natively since early 2024, and OpenAPI 3.2 already documents it — but as of July 2026, Spring hasn't shipped support yet, and browser vendors are still evaluating it. eCorpIT

A Practical Rollout Path

If you're running APIs behind a CDN, WAF, or cache layer, here's a reasonable way to approach adoption:

1. Audit your endpoints. List every POST route that's actually just a read operation with a complex payload. These are your future QUERY candidates.
2. Check your infrastructure. Review WAF rules, method allowlists, and CDN/proxy configs — anything written before June 2026 likely doesn't account for QUERY.
3. Review your caching strategy. Make sure cache keys correctly incorporate the request body, not just the URL.
4. Watch framework releases. Frameworks are the real bottleneck right now — expect native support to roll out gradually across 2026 and 2027. DEV Community
5. Experiment safely. If you control both client and server, there's nothing stopping you from prototyping QUERY behind a small middleware layer today.

Why This Matters

"Idempotent" may sound like jargon, but the term does real work in HTTP — it's the signal that tells reverse proxies and gateways they can safely cache complex query responses and automatically retry failed requests. That single guarantee is what search and retrieval-heavy APIs have been missing for two decades.

QUERY isn't a replacement for GET or POST — it's a purpose-built method for the read operations that never quite fit either one. The spec is final, it's backed by major infrastructure players like Cloudflare and Akamai, and the direction is clear. The only open question is how fast your stack catches up.