For 16 years, the list of HTTP methods every developer memorized in school stayed frozen: GET, POST, PUT, PATCH, DELETE. In June 2026, that list grew by one. The IETF published RFC 10008, standardizing a method called QUERY — the first new HTTP verb since PATCH landed back in 2010.

If you've ever built a search or filter endpoint and felt like neither GET nor POST was quite the right tool, this one's for you.

The problem: two bad options

Say you're building an endpoint to search orders with a bunch of filters — role, date range, nested conditions, pagination. You've got two choices today, and both are compromises.

Option 1: Cram it into a GET URL

http

GET /orders?select=surname,givenname,email&limit=10&match="email=*@example.*"

This is semantically correct — you're reading data, nothing changes on the server. But it falls apart fast:

URLs have practical size limits. Different proxies, CDNs, and servers enforce different caps, and you often don't know what they are until something breaks in production.
Encoding structured data — nested filters, arrays, special characters — into a URI-safe string is awkward and error-prone.
URLs get logged everywhere: server access logs, browser history, bookmarks, the Referer header. If your query contains anything sensitive, that's a real problem.

Option 2: Abuse POST

http

POST /orders/search
Content-Type: application/json

{ "select": ["surname", "givenname", "email"], "limit": 10 }

This solves the encoding and size problems, but it lies about intent. POST is not safe or idempotent by definition — nothing in the protocol tells a cache, proxy, or client that this "search" is actually a harmless read. So you lose caching, you lose safe auto-retries, and every intermediary along the way treats your read-only search like it might be mutating state.

This gap has existed since HTTP's early days, and developers have quietly worked around it for over a decade — usually by picking whichever compromise hurts less for a given endpoint.

Enter QUERY

RFC 10008 defines QUERY as a method that takes POST's request body and welds it to GET's safety guarantees. Here's the same search, done properly:

http

QUERY /orders HTTP/1.1
Host: api.example.org
Content-Type: application/json
Accept: application/json

{ "select": ["surname", "givenname", "email"], "limit": 10, "match": "email=*@example.*" }

The spec itself puts it plainly: a QUERY request asks the target resource to process the enclosed content in a safe and idempotent manner and then respond with the result of that processing.

What that buys you, concretely:

Safe & idempotent, officially. Unlike POST, caches and proxies can trust that a QUERY request doesn't change server state — because the spec guarantees it, not because you promise it in your API docs.
Automatic retries without side effects. QUERY requests can be repeated or restarted without any concern for partial state changes — something POST can never offer.
Actually cacheable. A QUERY response can be cached the same way a GET response can, as long as the cache incorporates the full request body into the cache key (not just the URL, since the URL alone no longer identifies the query).
A required Content-Type. Servers must reject a QUERY request if the Content-Type header is missing or doesn't match the body — meaning you can send JSON, GraphQL, JSONPath, SQL-like filters, whatever fits your API, as long as you declare the format.
Redirect support for expensive queries. A 303 See Other response can point the client at a pre-computed resource instead of running the query again, and the spec defines both Content-Location (fetch the results with a plain GET) and Location (repeat the same query without resending the body) headers for exactly this.

Where this actually matters

The clearest beneficiary is anything read-heavy with a query too complex for a URL:

GraphQL APIs. Every GraphQL query is read-only by design, yet the ecosystem has sent them over POST for years — sacrificing HTTP-level caching entirely and inventing workarounds like persisted queries just to claw some of it back. QUERY gives GraphQL a native path to HTTP caching without touching the query language itself.
Report builders and analytics dashboards, where a "search" might mean a filter object with a dozen nested conditions.
AI-powered search endpoints, where the query might literally be a JSONPath or vector-search expression too large and too structured for a query string.

Trying it today

You don't need to wait for full ecosystem support to experiment. Most HTTP clients let you send an arbitrary method string:

bash

curl -X QUERY https://api.example.com/orders \
  -H "Content-Type: application/json" \
  -d '{"role": "admin", "sort": "name", "page": 1}'

javascript

const response = await fetch("https://api.example.com/orders", {
  method: "QUERY",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify(query),
});

On the server side, since QUERY is just another method string, wiring it up in a Node/NestJS backend today mostly means bypassing your framework's built-in verb decorators and registering the route manually — something like binding a raw method-matching middleware in front of your controller, since @Get() / @Post() decorators don't yet recognize QUERY out of the box. Frameworks that already support arbitrary custom-method routing (Express-style middleware, Spring, Micronaut) can support it today with a bit of manual wiring; first-class annotations will take longer to arrive. .NET 10 is notably ahead of the curve here, already shipping HttpMethod.Query on the client and HttpMethods.Query / IsQuery on the server.

A pragmatic pattern several early adopters recommend: try QUERY first, and if the server responds 405 Method Not Allowed, fall back to POST. That way your client automatically upgrades as server support rolls out, with zero code changes later.

The honest catch: adoption will take time

This is a brand-new standard, and the ecosystem hasn't caught up yet:

Browsers can't send it from HTML forms. Standard forms only support method="GET" and method="POST" — there's an open WHATWG proposal to add method="query", but it's not resolved.
CORS preflight is mandatory. QUERY isn't on the browser fetch spec's list of "safelisted" methods, so any cross-origin QUERY request triggers a preflight OPTIONS request — extra latency you don't pay with a plain GET.
CDNs and proxies mostly don't recognize it yet. A CDN that sees an unfamiliar method will typically just pass it through without caching it, which quietly defeats the whole point until support lands. Worth noting: the RFC's co-authors work at Cloudflare and Akamai, which is a decent signal that CDN-level support may arrive sooner than framework-level support.
Legacy middleware, firewalls, and API gateways may reject an unrecognized method outright until vendors ship updates — the same slow-burn adoption curve PATCH went through after 2010.

Should you switch your endpoints today?

For public APIs with browser clients — not yet. You'll need a POST fallback anyway, and until fetch, CORS, and CDNs catch up, running both adds complexity without a real payoff.

For internal service-to-service communication where you control the whole stack (your own NestJS backend talking to your own Flutter or Next.js clients, for example) — it's reasonable to start experimenting now, especially for the heavier report/filter endpoints where POST-as-search has always felt like a hack.

Standard GET with simple, shareable, bookmarkable query params is still completely fine and shouldn't change. QUERY isn't replacing GET — it's finally giving complex, structured reads a home that isn't POST.

The takeaway

QUERY doesn't reinvent HTTP. It formalizes a pattern developers have been faking with POST for over a decade — taking POST's body flexibility and attaching GET's guarantees, so a read-heavy API can finally say what it means: this is a query, it's safe, cache it, retry it, trust it.

It'll likely take a year or more before browsers, CDNs, and frameworks fully support it — the same timeline PATCH went through. But if you're designing API architecture today, it's worth understanding now, so you're ready to reach for it the moment your stack catches up.

Reference: RFC 10008 — "The HTTP QUERY Method," IETF HTTPBIS Working Group, June 2026.