RFC 10008 Explained: The New HTTP QUERY Method Solves the Search API Problem

For decades, developers had three unsatisfying options to handle search related HTTP requests. A GET request, GET request with a body, or a POST request. All these three had it’s own issues. In June 2026, the new RFC 10008 was published putting a stop to that problem by adding a new HTTP verb – QUERY to the mix. This solves the standing problem of “How do you perform complex, read-only queries that require a request body”? Let us see that in detail.

Why was QUERY needed?

To understand this, let us define what a “Search” actually mean – it is a request the fetch a result set based on certain filtering parameters from the backend without any mutation.

For ages, developers implemented such requests using:

1. A plain GET request with query params
2. A GET request that has a body instead of query params
3. A POST request

Ok, so we had a way to handle it. But why do we need a new verb for doing the same job? That is where the underlying problems come out.

GET with query parameters

GET /products?category=laptop&brand=dell&price_lt=2000&…

Problem with the above request is, as the search becomes more complex, the number of characters in the URL gets longer and longer. Browsers and proxies have URL length limits and this may not be standardized. Also, complex nested filters dont fit in naturally with this method. It is also difficult to send arrays and objects over a URL.

Problem summary:

1. Uncontrollably long URLs
2. Browser/Proxy URL length limits
3. Complex nested filters dont fit natually
4. Difficult array and object handling in URL

GET with a body

GET /products
{
  "category": "laptop",
  "filters": {
    …
  }
}

This is technically possible. But the problem is, this way of implementation was never standardized. Many proxies, caches, and frameworks straight out ignores the body in GET or just strip GET request bodies.

Problem summary:

1. Never standardized
2. Proxies, chaces and frameworks just strip out the body.

Search with POST

POST /products/search
{
  "category": "laptop",
  "filters": {...}
}

This works. But POST means something entirely different.

POST means the request may mutate something on the server – either state or data. It cannot be “retried”. POSTs are not cached because it is supposed to mutate. Basically, POST is not meant for readonly operations.

We all ended up creating endpoints like POST /search, POST /query but we were not “creating” anything.

And that ends here. Now.

QUERY fixes this

Query combines two things – semantics of GET and a request body like POST.

Example:

QUERY /products
Content-Type: application/json
{
    "category": "Laptop",
    "brands": [
      "Dell",
      "Lenovo"
     ],
    "price": {
      "max": 2000
     },
    "sort": "rating"
}

The server returns matching products. No states changed. Cache-able, Retriable. Semantic – Exactly what the verb means!

All the problems from the previous section addressed with one verb!

Safe and Idempotent

One of the biggest features in the QUERY is explicitly defined as Safe and Idempotent.

Safe means – Running this request will not modify server state.- Same as GET.

Idempotent means, running the same query three times are identical – it responds the same way. Servers may log the requests, or update statistics. but the requested resource itself is not changed.

Comparison

Let me put it in this way – RFC 10008 is not adding any new capability. It is all about standardizing a patter the industry has already been using. This will let developers not implement overloaded POSTs for read-only searches because GET wasn’t designed for large or structured payloads. QUERY provides a clear, standardized alternative with the right semantics. It is safe like GET and robust like POST.

Don’t expect every language, framework, browser, CDN, or reverse proxy to support QUERY overnight. Like every new HTTP feature, adoption will take time. But now that the standard exists, support will gradually make its way through the ecosystem.

If you build APIs, it’s worth keeping an eye on your framework’s roadmap. As QUERY support arrives, you’ll finally be able to implement complex searches without bending the semantics of HTTP. Start using it and make the servers happy!

Power to you!