跪拜 Guibai
← All articles
Frontend

HTTP Gets Its First New Method in 16 Years: QUERY

By JarvanMo ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

QUERY gives complex, body-heavy read requests a first-class HTTP citizen. It eliminates the trade-off where teams had to choose between GET's caching and safety guarantees and POST's unlimited request body, and it standardizes behavior that every framework previously had to hack around.

Summary

The IETF published RFC 10008 in June 2026, adding the QUERY method to HTTP. It is the first new method since PATCH arrived in 2010. QUERY fills the gap between GET and POST: it sends a request body like POST but carries GET's safe and idempotent semantics, meaning it is read-only and can be retried without side effects. Crucially, QUERY responses are cacheable by default, a property that POST-based query workarounds could never guarantee.

A QUERY request can also return a URI for the query itself, not just its results. That lets a complex query be bookmarked, shared, and re-executed later to fetch fresh data. API surfaces that once sprawled across many GET endpoints can collapse into a single QUERY endpoint with conditions in the body.

Browser, CDN, and framework support will take until 2027–2028 to mature, but the standard is final. API designers can start planning for it now.

Takeaways
QUERY is a safe, idempotent HTTP method that accepts a request body for complex read operations.
RFC 10008 makes QUERY responses cacheable by default, unlike POST-based query workarounds.
Idempotency and cacheability are independent HTTP concepts; QUERY happens to have both, but PUT and DELETE are idempotent yet not cacheable.
A QUERY response can include a URI for the query itself, enabling bookmarking, sharing, and scheduled re-execution.
Adoption across servers, clients, and frameworks is expected to take until 2027–2028.
Conclusions

The 16-year gap between PATCH and QUERY reflects how long the industry tolerated the awkward POST-for-queries pattern before standardizing a fix.

QUERY's ability to return a URI for the query itself, rather than just its results, turns a one-off request into a shareable, repeatable resource — a subtle but powerful shift for API design.

The explicit separation of idempotency from cacheability in the RFC corrects a widespread misunderstanding that has led to poor caching decisions in many APIs.

Concepts & terms
Safe Method (HTTP)
An HTTP method that is read-only and must not alter server state. GET and QUERY are safe methods.
Idempotent Method (HTTP)
An HTTP method where multiple identical requests produce the same server-side effect as a single request. PUT, DELETE, and QUERY are idempotent, but idempotency does not imply cacheability.
Cacheable Response
An HTTP response that intermediaries like browsers, CDNs, and proxies are allowed to store and reuse. QUERY responses are cacheable by default under RFC 10008.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗