HTTP Just Got a New Method: Meet QUERY

HTTP has a new method, and it solves a problem most developers have probably encountered without realizing there was a better protocol-level answer. The problem usually starts innocently.

GET /posts?section=Coding&type=TUTORIAL&tag=react&tag=typescript&search=authentication&author=prasoon&sort=latest&page=3

A few filters are manageable. Then the application grows. You add nested filters, arrays, sorting rules, search expressions, date ranges, permissions and more conditions. Eventually, the URL becomes enormous. And somewhere along the way:

414 URI Too Long

The Old Problem With GET

GET is designed around retrieving a resource identified by a URI. Query parameters work extremely well for simple queries:

GET /posts?category=coding&page=2

But not every query is naturally small enough to fit comfortably inside a URI. The HTTP specification notes that request-target size limits can vary because a request may pass through multiple servers, proxies and other systems. It also notes that request URIs are more likely to be logged or appear in bookmarks. :contentReference[oaicite:1]{index=1} So what happens when the query becomes too complicated? For years, one common answer has been POST.

Why Developers Started Using POST

A complex search can be moved into the request body:

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

{
  "section": "Coding & Walkthroughs",
  "contentType": ["ARTICLE", "TUTORIAL"],
  "tags": ["React", "TypeScript"],
  "search": "authentication",
  "date": {
    "from": "2026-01-01",
    "to": "2026-09-25"
  }
}

This solves the URL-length problem. But there is an awkward part. The request is performing a read-only search, yet the HTTP method says POST. From the method alone, a client cannot know that this operation is safe and idempotent. That is the gap the new QUERY method is designed to address. :contentReference[oaicite:2]{index=2}

Meet QUERY

In June 2026, the IETF published RFC 10008, The HTTP QUERY Method, as a Standards Track specification. :contentReference[oaicite:3]{index=3} The basic idea is straightforward: Put the query in the request body, but use an HTTP method whose semantics explicitly describe it as a safe, idempotent query. The previous POST example can become:

QUERY /posts
Content-Type: application/json

{
  "section": "Coding & Walkthroughs",
  "contentType": ["ARTICLE", "TUTORIAL"],
  "tags": ["React", "TypeScript"],
  "search": "authentication",
  "page": 1
}

The URL remains short. The query itself can be as structured as the application needs.

GET vs POST vs QUERY

GET
↓
Retrieve a representation
Query commonly encoded in the URI


POST
↓
Submit content for processing
Can be used for complex searches
Not inherently safe or idempotent


QUERY
↓
Perform a query operation
Query is carried in request content
Explicitly safe and idempotent

That last part is what makes QUERY interesting. The RFC explicitly defines QUERY as both safe and idempotent, meaning a client can repeat the operation without expecting the query itself to change the state of the target resource. :contentReference[oaicite:4]{index=4}

What Does “Idempotent” Actually Give Us?

Imagine a request fails because the connection disappears immediately after the server processes it. For a safe, idempotent query, repeating the request is fundamentally different from repeating an operation that creates or modifies data. That makes mechanisms such as automatic retries much more natural. The RFC also defines QUERY responses as cacheable, although caching is more complicated than with GET because the request content becomes part of determining the cache key. :contentReference[oaicite:5]{index=5}

A Blog API Is a Perfect Example

Imagine a blog with hundreds of posts. A simple request might remain:

GET /api/posts?page=1&limit=10

That's perfectly reasonable. But eventually you might want:

{
  "sections": [
    "Technology & AI",
    "Coding & Walkthroughs"
  ],
  "contentTypes": [
    "ARTICLE",
    "TUTORIAL",
    "GUIDE"
  ],
  "tags": {
    "include": ["React", "AI"],
    "exclude": ["Beginner"]
  },
  "search": {
    "text": "authentication",
    "fields": ["title", "content", "tags"]
  },
  "publishedAfter": "2026-01-01",
  "sort": {
    "field": "createdAt",
    "direction": "desc"
  },
  "pagination": {
    "page": 1,
    "limit": 12
  }
}

Trying to serialize all of that into a URL is possible. But it isn't particularly pleasant. With QUERY:

QUERY /api/posts
Content-Type: application/json

{
  "sections": [
    "Technology & AI",
    "Coding & Walkthroughs"
  ],
  "contentTypes": [
    "ARTICLE",
    "TUTORIAL",
    "GUIDE"
  ],
  "tags": {
    "include": ["React", "AI"],
    "exclude": ["Beginner"]
  },
  "search": {
    "text": "authentication",
    "fields": ["title", "content", "tags"]
  },
  "pagination": {
    "page": 1,
    "limit": 12
  }
}

The API becomes much easier to reason about.

QUERY Doesn't Replace GET

This is important. The arrival of QUERY doesn't mean every GET request should become a QUERY request. For a normal resource:

GET /api/posts/the-code-that-remembered-me

GET is still exactly what you want. For a simple collection:

GET /api/posts?page=1&limit=10

GET is also perfectly reasonable. QUERY becomes interesting when the operation is fundamentally a complex query and the query representation itself is too large or structured to fit naturally into the URI.

There Is Another Interesting Detail

The RFC doesn't stop at putting the query into a request body. A server can assign a URI to the query or its results. That means a QUERY request can potentially return information that lets a client subsequently retrieve the equivalent resource using GET. The specification describes Location and Content-Location mechanisms for this purpose. :contentReference[oaicite:6]{index=6} Conceptually:

QUERY /api/posts
        ↓
Complex query
        ↓
Server processes it
        ↓
Result URI
        ↓
GET /api/query-results/abc123

That gives the protocol room to combine the strengths of both approaches.

But There Is a Catch

A new HTTP method doesn't automatically mean every piece of web infrastructure understands it. Browsers, frameworks, reverse proxies, CDNs, API gateways and other infrastructure need to support QUERY appropriately. The RFC also defines an Accept-Query response header that a resource can use to advertise supported query media types. :contentReference[oaicite:7]{index=7} So this isn't a reason to immediately rewrite every API you have. It is a new tool. And like every tool, its usefulness depends on the problem you're solving and the infrastructure you're using.

The Bigger Idea

The interesting part of QUERY isn't simply that HTTP gained another verb. It's that HTTP now has a more explicit answer to an awkward API design problem: What do you do when you need a complex, read-only query that doesn't fit comfortably inside a URL? GET puts the query in the URI. POST can put the query in the body, but doesn't inherently communicate that the operation is safe and idempotent. QUERY puts the query in the body while giving the operation those semantics directly.

Simple retrieval
        ↓
       GET

Complex query
        ↓
      QUERY

State-changing operation
        ↓
       POST

It's a small addition to HTTP. But small protocol changes can eventually influence how entire layers of software are designed. The interesting question now isn't whether QUERY exists. It does. The interesting question is how quickly the rest of the web stack catches up.