HTTP gets a QUERY method: a safe, idempotent verb that carries a request body

REST APIs have long been stuck with a bad choice when filters get complicated. GET keeps everything in the URL, which works for simple parameters but breaks down with deep nesting, arrays, or complex relational logic — URLs balloon past length limits, encoding inflates request size, ambiguous array conventions proliferate, and query strings end up in server logs. Stuffing a body into a GET request is technically not forbidden but is unreliable in practice, since clients, proxies, and servers handle it inconsistently (some drop it, some reject it outright). The common fallback, POST, solves the body problem but lies about intent: it’s defined as non-idempotent and write-oriented, which defeats automatic retries and prevents caches and middleware from recognizing a request as read-only.

The newly specified QUERY method fills that gap. It behaves essentially like GET but legitimately carries a request body, and it is defined as safe and idempotent — the semantics search endpoints actually need. Responses can be cached, with the important caveat that implementations must fold the request body into the cache key.

The practical catch is maturity. Support across clients, proxies, and web servers is thin and likely to remain so for years (Kreya, the author’s API client, only added native support in version 1.20). Plain GET-with-URL-parameters remains perfectly valid and should be left alone where it works, especially since QUERY requests can’t be bookmarked or shared as links. The guidance: reach for QUERY as a cleaner replacement for POST-based search only when GET genuinely falls short — and test that your whole request path tolerates it first.