HTTP QUERY: The First New HTTP Method in Decades

For years, developers have been forced to choose between two imperfect options whenever they needed to perform a complex search or filtering operation.

• Use GET, which technically shouldn't contain a request body.
• Use POST, even though the request is only reading data.

Neither option accurately describes what the request is actually doing.

To solve this long-standing problem, the HTTP Working Group introduced a new HTTP method called QUERY.

This is the first standardized HTTP request method added in decades, making it one of the biggest updates to HTTP in years.

The Problem with GET

GET has always been the standard method for fetching data.

GET /users

Simple.

But modern applications rarely perform simple queries.

Imagine searching products with dozens of filters:

• categories
• price ranges
• brands
• ratings
• colors
• stock availability
• sorting
• pagination

Using GET quickly becomes messy.

GET /products?category=laptop&brand=apple&minPrice=1000&maxPrice=2500&rating=4&sort=price&page=2&color=silver

Now imagine even larger search payloads.

Problems include:

• Extremely long URLs
• URL length limitations
• Difficult debugging
• Sensitive filters appearing in logs
• Poor readability
• Nested JSON impossible to represent cleanly

Developers naturally started sending JSON instead.

Why POST Wasn't the Right Answer

Most APIs solved this by doing something like:

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

{
  "category": "Laptop",
  "brands": ["Apple","Dell"],
  "price": {
    "min": 1000,
    "max": 2500
  },
  "sort": "price"
}

It works.

But there's a semantic problem.

POST means:

"I want to create, modify, or process something."

Searching data doesn't create anything.

The request is completely read-only.

Using POST for searches has always been considered a workaround rather than the correct HTTP design.

Enter HTTP QUERY

QUERY was created specifically for this situation.

It allows clients to send a request body while still clearly communicating that the operation is safe and read-only.

Example:

QUERY /products
Content-Type: application/json

{
  "category": "Laptop",
  "brands": ["Apple","Dell"],
  "price": {
    "min": 1000,
    "max": 2500
  },
  "page": 2,
  "sort": "price"
}

The server understands:

• This request only reads data.
• Nothing should be created.
• Nothing should be updated.
• Nothing should be deleted.

Safe Doesn't Mean Small

Many developers confuse GET with "small request."

That's not what HTTP defines.

A request is considered safe if it does not change server state.

Examples of safe operations:

• Searching products
• Filtering users
• Analytics queries
• Reports
• AI retrieval requests
• Database lookups

These are exactly the kinds of operations QUERY is designed for.

GET vs POST vs QUERY

Why Not Just Allow GET Bodies?

Technically, some servers already accept GET request bodies.

The problem is the web ecosystem.

Many tools, proxies, browsers, gateways, CDNs, caches, frameworks, and load balancers either ignore GET bodies or don't handle them consistently.

Changing GET behavior today would break compatibility across the internet.

Creating a new HTTP method avoids those issues while giving developers a clear, standardized solution.

When Should You Use QUERY?

QUERY is ideal for:

Product Search

{
  "category": "Laptop",
  "price": {
    "min": 1000,
    "max": 3000
  }
}

Advanced User Filtering

{
  "country": "India",
  "age": {
    "min": 18,
    "max": 30
  },
  "verified": true
}

Analytics Dashboards

Large report definitions with:

• date ranges
• dimensions
• metrics
• filters
• grouping
• sorting

AI Applications

Retrieval APIs often require:

• embeddings
• metadata filters
• namespaces
• ranking options

QUERY fits these use cases much better than POST.

When Should You NOT Use QUERY?

Avoid QUERY if your endpoint:

Creates data

POST /users

Updates data

PUT /users/12

Partially updates

PATCH /users/12

Deletes data

DELETE /users/12

QUERY should never modify server state.

Benefits of QUERY

• Correct HTTP semantics
• Read-only by design
• Supports complex JSON payloads
• Cleaner API design
• Easier to document
• Better communicates developer intent
• Eliminates unnecessary POST endpoints for searches

Current Adoption

QUERY has recently been standardized, but support across browsers, frameworks, proxies, API gateways, and HTTP libraries is still evolving.

Today, many APIs continue using POST for complex searches because existing infrastructure may not yet recognize QUERY.

As tooling matures, expect more servers and frameworks to add native support.

Should You Start Using It Today?

If you're building a brand-new API and control both the client and server, QUERY is worth keeping an eye on.

For public APIs, it's still wise to verify that your clients, gateways, proxies, load balancers, and SDKs support QUERY before adopting it in production.

Until ecosystem support becomes widespread, POST remains the most compatible option for complex read-only searches.

Final Thoughts

HTTP QUERY isn't about replacing GET or POST.

It's about filling a gap that developers have worked around for years.

GET was too limited for complex payloads.

POST was semantically incorrect for read-only operations.

QUERY provides a cleaner, standards-based solution that accurately expresses developer intent while preserving HTTP semantics.

As support grows across the web ecosystem, QUERY has the potential to become the preferred method for complex, read-only API requests.