HTTP Finally Gets a New Verb: Meet QUERY (RFC 10008)

For over 15 years, backend developers, API designers, and frontend engineers have lived by a strict, self-imposed set of rules. If you want to create a resource, you use POST. If you want to replace it, PUT. If you want to fetch it, GET.

But what happens when you need to fetch a resource using a massive, deeply nested JSON filter, a complex SQL string, or a large GraphQL block?

Historically, we had to choose between breaking HTTP semantics or risking massive URL breakages. That era is officially over. In June 2026, the IETF officially published RFC 10008, standardizing a brand-new HTTP method: QUERY. This is the first major addition to the core HTTP verbs since PATCH was standardized back in 2010.

Here is everything you need to know about why QUERY exists, how it works, and how it’s going to fix API design layout.

The Broken Workarounds: GET vs. POST

To understand why QUERY is such a big deal, we have to look at the architectural compromises developers have been forced to make for nearly two decades.

1. The GET Problem (The Payload Dilemma)

The GET method is semantically perfect for retrieving data. It is safe (it doesn't modify server state) and idempotent (replaying it 10 times yields the same result). This allows browsers, CDNs, and proxies to aggressively cache GET requests.

However, GET parameters must live entirely inside the URL string:

GET /orders?select=id,date,total&filter[status]=delivered&filter[date][gt]=2026-01-01&limit=50 HTTP/1.1

This breaks down fast because:

• URL Length Limits: Many servers, routers, and proxies drop or crash on URLs longer than 2,000 to 8,000 characters.
• Security & Information Leakage: Query parameters are routinely dumped into plain-text server logs, exposing potentially sensitive user data or internal IDs.
• Encoding Nightmares: Complex nested objects become an unreadable mess of percent-encoded characters (%20, %5B, %5D).

Can't we just put a body in a GET request?
Technically, the HTTP specification doesn't explicitly forbid it, but it states that a body on a GET request has no defined semantics. In practice, many enterprise firewalls, proxy layers, and web servers will straight up drop the body or reject the request entirely.

2. The POST Problem (The Semantic Sacrifice)

To bypass GET limits, developers turned to POST for search endpoints (e.g., POST /orders/search). While this permits a massive JSON payload in the request body, it ruins HTTP ergonomics:

• POST is explicitly defined as non-idempotent.
• Because intermediaries and browsers must assume a POST request alters data, it cannot be automatically cached by your network infrastructure.
• If a user's network drops mid-request, browsers cannot safely auto-retry a POST without warning the user ("Are you sure you want to resubmit this form?").

The Solution: QUERY

The QUERY method is the missing piece of the puzzle. It takes the request body support of POST and marries it with the safe, idempotent, and cacheable semantics of GET.

[ HTTP QUERY ] = [ GET Semantics: Safe & Idempotent ] + [ POST Capabilities: Request Body Payloads ]

What a QUERY Request Looks Like

Instead of packing everything into a single fragile URL line, you can pass structured JSON, SQL, or GraphQL cleanly in the body:

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

{
  "select": ["id", "date", "total"],
  "filter": {
    "status": "delivered",
    "date": { "$gt": "2026-01-01" }
  },
  "limit": 50
}

Key Features of QUERY

• Explicitly Safe & Idempotent: Because it's registered with IANA as safe, clients, reverse proxies, and browsers know out of the box that it will never mutate server state. It can be safely automatically replayed on a dropped connection.
• Natively Cacheable: Unlike POST, responses to QUERY can be cached. However, unlike GET (which uses the URL as a cache key), a caching layer handling a QUERY request hashes and incorporates the request body into the cache key.
• The Accept-Query Header: The specification introduces a way for servers to advertise what kind of query formats they accept via a handshake or an OPTIONS call:

  Accept-Query: application/json, application/sql, application/graphql

How It Impacts the Future of Web Development

The standardization of QUERY is a massive win for modern web architectures:

1. GraphQL Demilitarized: Most GraphQL queries are read-only but are sent via POST because the query strings are too large for a URL. QUERY allows GraphQL to align perfectly with native HTTP semantics.
2. Cleaner Analytics & Search Backends: Dashboard applications, report builders, and complex internal search matrices will no longer need custom "safe-retry" wrappers to handle POST requests masquerading as lookups.
3. Privacy Boost: Sensitive parameters like search terms, user filters, or PI-adjacent identifiers stay hidden inside the encrypted TLS payload body rather than leaking into corporate proxy traffic logs.

When Can You Use It?

Because RFC 10008 was just finalized in mid-2026, native support is still rolling out. While core HTTP libraries (like Go’s ServeMux or Node.js) can handle it immediately because HTTP methods are fundamentally just strings, it will take time for CDNs (like Cloudflare and Akamai, who co-authored the spec), browsers, and major frameworks to implement standard-compliant body caching and native client wrappers.

Expect QUERY to slowly become a baseline requirement for high-performance REST and RPC APIs over the next couple of years.