Why HTTP Needed the QUERY Method

HTTP Finally Gets a New Request Method: Meet QUERY

For years, HTTP developers have worked with a familiar set of request methods—GET, POST, PUT, PATCH, and DELETE. These methods have served the web remarkably well, but one common problem has always been awkward to solve:

How do you send a complex query to the server without pretending it's a state-changing operation?

The answer was usually one of two compromises:

• Stuff everything into a long GET URL.
• Use POST even though you're only reading data.

Now, HTTP has a better answer.

With RFC 10008, the HTTP ecosystem introduces a new standardized request method: QUERY.

The Problem with GET

GET is the natural choice for retrieving data because it is:

• Safe (doesn't modify server state)
• Idempotent
• Cache-friendly

However, GET requests carry parameters in the URL.

Imagine searching an e-commerce website with dozens of filters:

GET /products?category=laptops&brand=Dell&brand=Lenovo&priceMin=500&priceMax=1500&sort=-rating&page=3

As filters become more complex, URLs become:

• Difficult to read
• Hard to maintain
• Limited by URL length restrictions in some environments

Even worse, expressing deeply nested filters in a query string can become nearly impossible.

Why Developers Used POST

To avoid enormous URLs, many APIs switched to:

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

{
  "category": "laptops",
  "brands": ["Dell", "Lenovo"],
  "price": {
    "min": 500,
    "max": 1500
  },
  "sort": "-rating"
}

This works technically.

But semantically, it's misleading.

POST is intended for operations that may change server state, while a search is simply retrieving information.

This mismatch affects caching, retries, API documentation, and HTTP semantics.

Enter QUERY

The new QUERY method is designed specifically for read-only operations that require a request body.

Example:

QUERY /products
Content-Type: application/json

{
  "category": "laptops",
  "brands": ["Dell", "Lenovo"],
  "price": {
    "min": 500,
    "max": 1500
  },
  "sort": "-rating"
}

Now the intent is clear:

• The client is retrieving data.
• The request can include a rich JSON body.
• The server promises not to modify server state.

Key Characteristics

QUERY is:

• Safe
• Idempotent
• Designed to support a request body
• Intended for complex retrieval operations

In many situations, it becomes the ideal middle ground between GET and POST.

GET vs POST vs QUERY

Feature	GET	POST	QUERY
Read data	Yes	Yes	Yes
Request body	No (not generally used)	Yes	Yes
Safe	Yes	No	Yes
Idempotent	Yes	No	Yes
Complex filters	Limited	Yes	Yes
Correct HTTP semantics	Yes	No (for reads)	Yes

Real-World Use Cases

QUERY is especially useful for:

• Advanced product searches
• Analytics dashboards
• Business intelligence queries
• Graph-style filtering
• GIS and map searches
• Large reporting APIs
• Log search platforms
• AI and vector database queries

Anywhere a client needs to send a structured query without changing data, QUERY is a natural fit.

Will It Replace POST?

Not immediately.

The web ecosystem is vast. Browsers, HTTP libraries, proxies, API gateways, CDNs, and frameworks all need to support the new method. Existing APIs that already use POST /search will likely continue to do so until support for QUERY becomes widespread.

Over time, however, new APIs may adopt QUERY to better express read-only operations.

What This Means for API Designers

For years, developers had to choose between:

• Correct semantics (GET) with awkward URLs
• Convenient request bodies (POST) with incorrect semantics

QUERY removes that trade-off.

When an endpoint retrieves data but requires a structured request body, developers no longer have to misuse POST.

Final Thoughts

New HTTP methods are introduced very rarely.

The introduction of PATCH was a significant milestone, and now QUERY represents another meaningful evolution of the HTTP protocol.

It is a small addition with a significant impact, making HTTP more expressive while preserving the principles that have made it successful for decades.

As support spreads across frameworks, servers, proxies, and client libraries, QUERY has the potential to become the standard choice for complex, read-only operations.

HTTP doesn't evolve often, but when it does, it's worth paying attention.