Testing HTTP's Newest Method: A QUERY Proof-of-Concept in Node.js
RFC 10008 formally defines QUERY — a safe, idempotent HTTP method that can carry a request body. I built a small Node.js implementation to see what that actually looks like in practice.
GET can't carry a meaningful body, and its query string has practical size limits that vary by server, proxy, and CDN — nobody agrees on exactly where. POST can carry a body, but it's neither safe nor idempotent by definition, so it can't be cached or safely auto-retried. Every API that needs to send a large, structured search or filter query has had to pick one of these two imperfect tools.
QUERY, formalized in RFC 10008, closes that gap. It's a new HTTP method that behaves like GET in the ways that matter — safe, idempotent, cacheable — but carries content the way POST does. Same semantics as GET's intent, none of the URI-length ceiling.
I built a small Node.js proof-of-concept to see what implementing this actually looks like, not just read the spec.
What the PoC does
It's a minimal HTTP server that accepts QUERY requests, parses the request body as the query payload (the same way you'd read a POST body), processes it, and returns results — while being explicit that responses to a given query are safe to cache and requests are safe to retry automatically, since nothing about a QUERY request changes server state.
What stood out building it
Most HTTP frameworks and tooling — routers, middleware, even some low-level HTTP libraries — have GET/POST/PUT/DELETE baked in as first-class citizens, with QUERY not yet universally recognized. Getting a raw Node.js server to correctly parse and route a QUERY method meant working closer to the HTTP layer than most day-to-day API work requires — a good reminder of how much abstraction sits between "day-to-day backend work" and the actual protocol underneath it.
Why this is worth knowing about
RFC 10008 only just reached Proposed Standard status. Client and server support is still catching up — most HTTP libraries, browsers, and API gateways don't have native QUERY support yet. But the problem it solves is real and common: any team building search, filter, or reporting APIs with more than a few parameters has run into GET's URI limits or reached for POST as a workaround, giving up caching and safe retries in the process. Worth watching as tooling catches up.
The proof-of-concept is public: github.com/suvendusgiri/http-query-poc