HTTP QUERY: A Draft Method That Reads Like GET, Sends Like POST

QUERY is a new HTTP method currently working its way through the IETF as a draft — it is not yet a finished, ratified standard, and support across browsers, servers, and libraries is still patchy and evolving. The idea behind it is simple to state: read-only like GET, but with a request body as flexible as POST's.

Read-only, like GET

QUERY carries the same safety guarantees as GET. It's safe (it must not change anything on the server), idempotent (sending it once or a hundred times has the same effect), and cacheable. Semantically, it's still just a way to ask a server for data — never to create, update, or delete it. Anything that behaves like a query rather than a command is a candidate for QUERY, in the same spirit as GET.

But flexible, like POST

Where QUERY departs from GET is the request body. GET requests are conventionally expressed entirely through the URL, and while nothing in HTTP technically forbids a GET body, in practice browsers, proxies, CDNs, and server frameworks routinely ignore or strip one — so it was never something you could rely on. That's fine for a simple lookup, but falls apart for a search with dozens of filters, a bulk lookup of thousands of IDs, or a GraphQL-style query document, all of which are awkward or impossible to cram into a URL.

QUERY solves this by allowing a request body just as freely as POST does — structured JSON, form data, whatever the API defines — without giving up GET's read-only guarantees. You get POST's flexibility for describing what you want, combined with GET's promise that asking for it doesn't change anything.

Still a draft — proceed accordingly

Because QUERY hasn't finished standardization, treat it as an emerging option rather than something to adopt without checking support first. Expect gaps: some HTTP client libraries only allow a body on POST, PUT, or PATCH by default, and some proxies or CDNs may not recognize QUERY at all yet. If you're designing a new API endpoint today, QUERY is worth knowing about; if you're consuming one, confirm your tooling actually supports sending a body on it before you depend on it in production.

What it means for monitoring

As more APIs pick up QUERY for search and bulk-lookup endpoints, the same rule applies as with any other method: your monitor should send what real clients actually send. A GET check against a QUERY-only endpoint may return an error even though the service is healthy, so confirm your monitoring tool can send a body on QUERY requests. And because QUERY is designed to be cacheable like GET, a "healthy" response from a monitor may be coming from a cache rather than the origin — worth keeping in mind when you interpret the result.