Ever shipped a /search endpoint that's technically a POST but really just runs a SELECT? I've seen it in dozens of production APIs. GET can't reliably carry a body, so the filter ends up crammed into the URL until it hits a length limit, or it gets shoved into a POST that lies about what the request actually does.
HTTP just closed that gap. RFC 10008 defines a new method called QUERY. It carries a body like POST, but it's defined as safe and idempotent like GET. That's not a technicality: gateways that refuse to auto-retry a POST (because it might mutate state) can retry a QUERY freely, and caches that won't touch a POST response can store a QUERY response the same way they'd store a GET.
Server-side support is already ahead of where you'd expect. Node.js has recognized QUERY since 22.2.0, released in June 2024, two years before the RFC was finalized. OpenAPI 3.2 documents it as a first-class operation type. nginx has an open PR but nothing merged yet. Browsers support it through fetch() today, though cross-origin calls need a CORS preflight since QUERY isn't a safelisted method.
I go through why POST and GET both fall short here, how Accept-Query and the stored-query pattern work, why this maps cleanly onto GraphQL's query vs mutation split, and a Go server example using net/http's method-pattern routing that you can curl and test in a minute.
Originally published on abgeo.dev: https://www.abgeo.dev/blog/http-query-method/
Top comments (0)