In mid-June 2026, the IETF published the HTTP QUERY method as RFC 10008. Days later, the author of the developer tool Kreya wrote a long explainer on what the new method actually solves, and on June 23 it reached the Hacker News front page with hundreds of comments. For a single HTTP method to draw that much attention, the reason is simple: it steps directly on a pain every API designer has felt.
QUERY’s position in one sentence: it is safe and idempotent like GET, but it can carry a request body.
From Draft to RFC
RFC 10008 was written by Julian Reschke, James M. Snell of Cloudflare, and Mike Bishop of Akamai, and it grew out of the HTTPBIS working group draft draft-ietf-httpbis-safe-method-wbody. That draft has history — Hacker News users have posted and debated it since 2022, and version 14 made the front page again in November 2025. It has now landed as a Proposed Standard. That the process took years says something: whether a safe method may carry a body was never settled among engineers, and it ultimately took an RFC to close the argument.
GET’s Limits and POST’s Semantic Debt
The root problem: push a complex read-only query into a GET URL and you hit URL length limits; special characters need encoding; sensitive parameters ride the URL straight into server logs; and every API invents its own convention for arrays and nested structures. Switching to POST works technically, but the semantics are entirely wrong — POST is not idempotent, automatic retries risk side effects, and middleware has no way to treat the request as read-only or cacheable. As for “GET with a body,” the specs never explicitly ban it, but they clearly discourage it, and implementations diverge as a result: some reject the request, some silently strip the body, some process it anyway.
QUERY’s answer is a new method rather than a redefinition of GET. The query itself is defined by the request content and its media type — the spec lists form-urlencoded, SQL, JSONPath, and XSLT as possible shapes — and it also covers content negotiation, error codes (400, 415, 422, 406), result addresses returned via Content-Location and Location, redirection, conditional requests, and range requests.
Caching and Accept-Query
Two design points deserve attention. The first is caching: QUERY responses can be cached, but the RFC states that implementations “must be careful to incorporate the request content into the cache key” — otherwise different queries collide into one cached response. That is the easiest trap when rolling your own support, and it makes custom caching harder than GET’s. The second is the new Accept-Query response header: a Structured Field that lets a server advertise which query media types it accepts, so clients no longer have to guess.
On ecosystem adoption, temper expectations. The author is blunt that support is still limited — some clients, proxies, and web servers may simply reject QUERY requests — and full ubiquity is expected to take years. For teams running internal gateways, caches, or service meshes, that means an audit before enabling QUERY anywhere: every intermediary along the request path gets a vote on whether an unknown method passes through. Kreya itself added native support in version 1.20.
How API Designers Should Adopt It
The explainer’s advice is pragmatic: keep simple GET-based queries exactly as they are; if users need shareable, bookmarkable links, GET remains the right answer; only move complex read-only queries to QUERY, and test every hop along the request path before shipping.
There is one more layer for agent and API tooling developers: once structured queries move into the request body, they are free of URL encoding and length limits, and queries generated by programs or models no longer have to be squeezed into a query string. The HTTP method family has been static for years, and QUERY is one of the few genuinely new primitives — how long proxies, frameworks, and clients take to accept it everywhere is still unknown, but the direction is now fixed.
Sources
- RFC 10008: The HTTP QUERY Method — RFC Editor
- The new HTTP QUERY method explained — Kreya
- RFC 10008 — IETF Datatracker
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.