QUERY: HTTP's first new method in years

In June 2026 the IETF published RFC 10008, officially adding a new HTTP method: QUERY — the first addition of its kind since PATCH in 2010.

The old problem

Every API that grows eventually hits the same wall: a search or filtering endpoint, and every available option is incomplete.

GET is safe and cacheable, but can't carry a body. Filters get crammed into the URL, every proxy has its own opinion about acceptable length, and URLs end up in logs with everything in them.
POST carries a body just fine, but the protocol itself has no idea it's a read-only operation. No automatic caching, no safe retries.

The familiar result: POST /search in nearly every project — a workaround that works, but it's routing around the protocol rather than using it.

What QUERY does

Simply put: safe and idempotent like GET, carries a body like POST.

QUERY /products HTTP/1.1
Content-Type: application/json

{
"filters": { "category": "electronics", "price_max": 500 },
"sort": "price_asc",
"limit": 20
}

The protocol now knows this request is read-only, which unlocks three direct benefits:

Safe retries — any client or proxy can automatically repeat the request without fear of partial state changes.
Caching — QUERY responses are cacheable, provided the cache key includes the request body itself.
Clear semantics — WAFs, gateways, and any intermediary layer can understand the request's intent from the method alone.

Accept-Query

The standard also adds a new header, Accept-Query, letting a server advertise which query formats it supports:

Accept-Query: application/jsonpath, application/sql;charset="UTF-8"

A client can check before sending, instead of guessing and getting a 415 back.

Before using it in production

The practical reality matters here:

Ecosystem support is still forming. Many frameworks, libraries, and load balancers don't recognize QUERY yet — some reject the request before it ever reaches your code.
CORS: the method isn't on the fetch spec's safelist, so any cross-origin QUERY from a browser triggers a preflight first.
Caching cuts both ways: body normalization at the cache layer must match how the server interprets the query, or you get false cache hits.

Takeaway

QUERY isn't a trend — it closes a gap that has existed in HTTP from the beginning. APIs with complex search and filtering are the first beneficiaries. The sensible path: start with it internally, where you control both client and server, and keep POST /search as a fallback until support matures.

Reference: RFC 10008 — The HTTP QUERY Method