The new HTTP QUERY method explained

Original Article ↗ Hacker News Discussion ↗

What QUERY Is Meant to Solve

  • Seen as “GET with a body” formalized: safe, idempotent, cacheable, but can carry a request body.
  • Intended to replace hacks like GET-with-body or POST-for-queries (e.g., search, GraphQL queries).
  • Advocates say it clarifies semantics for intermediaries: “this can be cached, is read-only, and has a body.”

Why Not Just Fix GET?

  • One camp: simply standardize GET-with-body; QUERY is redundant “XKCD standards” bloat.
  • Counterpoint: many existing proxies, WAFs, CDNs, and frameworks strip or reject GET bodies or treat them as meaningless.
  • Changing GET semantics would create undefined behavior in legacy systems; a new method can cleanly fail with 405 and allow fallback to POST.
  • Some argue both paths require updating infrastructure anyway; they see QUERY as marketing rather than technical necessity.

Compatibility, Middleboxes, and Browsers

  • Concerns that badly maintained “black box” middlewares may mishandle new verbs or crash.
  • Others say standards must evolve despite legacy gear; broken infra should be fixed.
  • Several note browsers are unlikely (or at least not guaranteed) to implement QUERY soon; that limits web-facing adoption.
  • Accept-Query header and OPTIONS/405 are cited as mechanisms to negotiate support.

Proposed Use Cases

  • Search APIs like Elastic/OpenSearch currently abusing GET-with-body or POST; QUERY would be a natural fit.
  • GraphQL: use QUERY for read-only queries, POST for mutations.
  • Complex filtering/search in web apps: JSON bodies instead of long query strings.
  • Reverse image search and other file- or binary-based queries.

Caching, Semantics, and REST

  • QUERY is defined as cacheable and idempotent; this opens CDN/proxy caching unlike POST.
  • Skeptics note practical cache keys: bodies lack a standard canonical form (JSON ordering, whitespace), complicating shared caches.
  • Some argue QUERY improves REST/CRUD clarity by separating simple GET-by-URL from more complex queries; others say you can model queries as resources (POST to create, then GET).

Security, WAFs, and Practical Pain Points

  • Many note real-world systems that reject or strip GET bodies (WAFs, CloudFront, strict API gateways).
  • QUERY is seen as a way to avoid these undefined behaviors and security rules that treat GET-with-body as suspicious.
  • Others warn QUERY itself won’t be supported by such systems initially, so migration remains non-trivial.