The Kreya explainer frames QUERY as overdue infrastructure: search endpoints have spent two decades cramming filters into query strings, smuggling bodies through GET, or capitulating to POST and losing cacheability. QUERY restores the read path by being safe, idempotent, and body-bearing, with cache keys computed from method + URI + body.
The editorial argues that Elasticsearch's GET-with-body and Apollo GraphQL's POST-everything pattern are both symptoms of the same missing primitive. RFC 7231 left GET bodies with 'no defined semantics,' which is why Fetch refuses to send them and nginx strips them — QUERY is the replacement the web's read path has been missing.
The IETF's HTTP Working Group has been moving a new request method, QUERY, through standardization, and a fresh explainer from the Kreya team hit 179 on Hacker News this week. The draft (`draft-ietf-httpbis-safe-method-w-body`) defines QUERY as a method that is both safe and idempotent — the same semantic guarantees as GET — but with one critical difference: it carries a request body.
The motivation is mundane and overdue. Search endpoints have been abusing HTTP for two decades: cramming complex filters into query strings until they hit URL length limits, smuggling bodies through GET in violation of the spec, or surrendering to POST and losing every cacheability and safety property in the process. Elasticsearch's `_search` endpoint is the canonical example — it accepts a JSON body on GET, which works in practice but makes every HTTP purist twitch. Apollo's GraphQL clients went the other way and POST everything, which means no CDN caching of identical queries without bolt-on persisted-query schemes.
QUERY ends the workaround era. The method signals to servers, proxies, and caches: *this is a read, treat it like one, but I have structured input that doesn't fit in a URL*. Cache keys are computed from the method, URI, and the request body — so two identical QUERY requests with the same JSON filter hit the same cache entry, just as two identical GETs would.
The gap QUERY fills is older than most working developers. RFC 7231 explicitly said GET request bodies have "no defined semantics" — implementations were free to ignore them, drop them at proxies, or reject them outright. That ambiguity is why Fetch in browsers refuses to send a body with GET, why nginx strips GET bodies by default, and why every "why doesn't my GET body work?" Stack Overflow thread ends with "use POST." The web's read path quietly lost its body 25 years ago and nobody built a replacement until now.
Compare the three options a backend engineer faces today for a complex search endpoint:
- GET with query string: Cacheable, safe, idempotent. But URLs cap at ~2KB in practice (8KB in spec, less at CDNs), filters become URL-encoded JSON soup, and sensitive query parameters end up in access logs and Referer headers. - GET with body: Works in curl, breaks in browsers, undefined in spec, silently dropped by intermediaries. A footgun. - POST: Body works fine, but the request is now unsafe (a proxy can't retry it) and uncacheable by default. You lose every property that made REST tractable.
QUERY threads the needle. The HN discussion is mostly favorable but skeptical of the rollout path. The top concern isn't the spec — it's the years of WAFs, corporate proxies, API gateways, and load balancers that will reject any method they don't recognize with a 405 or, worse, a silent drop. One commenter noted that even PATCH, standardized in 2010, still hits 405s on legacy infrastructure in 2026. QUERY is starting from zero.
The draft anticipates this. It defines a fallback pattern: send a POST with a `X-HTTP-Method-Override: QUERY` header (or similar), and servers that understand QUERY semantics can opt in while wire-level intermediaries see a familiar POST. It's the same migration pattern PATCH used, and it works, but it also means the cacheability win — the actual reason to adopt QUERY — disappears at every hop that doesn't speak the real verb. You get the semantics without the performance, which is half the prize.
There's also a quieter benefit worth naming: observability and security. Query strings end up in nginx access logs, CloudFront logs, browser history, and Referer headers leaked to third-party scripts. Moving the query payload into a request body means your search filters — which often contain user IDs, internal taxonomies, or commercially sensitive predicates — stop bleeding into log aggregators and analytics pixels. That's not a spec property of QUERY specifically, but it's a real reason teams will want to migrate off URL-stuffed GETs even before CDN support catches up.
If you ship a search, filter, or report API today, your near-term play is unchanged: keep using POST, but start designing your endpoints as if QUERY existed. That means: treat the request as idempotent in your handler (don't mutate state, don't increment counters), compute deterministic cache keys from the body, and avoid POST-only headers like CSRF tokens that would block a future verb swap. When CDNs and your API gateway add QUERY support, the migration is a routing change, not a redesign.
For GraphQL shops, QUERY is the verb the spec always needed. Persisted queries exist precisely because POST broke caching; if Apollo, urql, and Relay add QUERY transports — and there's no reason they shouldn't — the persisted-query dance becomes optional rather than mandatory for cache hit rates. Watch for `@apollo/client` and `graphql-request` to add experimental QUERY support within a release cycle of Chromium and Node shipping it.
Backend frameworks will move first because they cost nothing to update: a route decorator, a method matcher, done. Expect Express, Fastify, Hono, ASP.NET Core, and Spring to add QUERY routing in the next minor versions. The slow path is everything in front of your application: nginx, Envoy, HAProxy, Cloudflare, Fastly, AWS API Gateway, every corporate WAF. Cloudflare and Fastly typically lead on new HTTP features; AWS API Gateway typically lags by 18+ months. Plan accordingly.
QUERY is a small spec change that retires a large pile of accumulated hacks. It won't trend on Twitter the way a new framework does, but five years from now the GraphQL-over-POST workaround, the Elasticsearch GET-with-body wink, and the URL-length-limit horror stories will all read like artifacts of an earlier web — the same way nobody writes `XMLHttpRequest` anymore. The interesting question isn't whether QUERY ships; the draft is solid and the use case is real. It's whether the infrastructure layer adopts it fast enough that anyone can actually use it before the next workaround calcifies into permanence.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.