For nearly 15 years, developers have been forced to choose between two imperfect options for complex API queries: abuse GET or misuse POST. That’s finally changing.

The web has evolved dramatically.

We have AI applications sending thousands of search requests, analytics dashboards generating complex filters, GraphQL APIs, vector databases, enterprise search engines, and recommendation systems that require rich query payloads.

Yet HTTP itself hasn’t evolved much to support these use cases.

Until now.

The Internet Engineering Task Force (IETF) has officially published RFC 10008, introducing a brand-new HTTP method:

QUERY

This is the first major addition to HTTP semantics in many years and arguably the biggest change developers will notice since PATCH became widely adopted.

If you’ve ever wondered:

  • Why GET requests shouldn’t have a body

  • Why POST is often used just for searching

  • Why search endpoints never felt “RESTful”

then QUERY is the answer you’ve been waiting for.

A Quick Refresher: Understanding HTTP Methods

Before understanding QUERY, it’s important to understand why existing methods weren’t enough.

GET

Retrieves data.

GET /users/10

Characteristics

  • Safe ✅

  • Idempotent ✅

  • Cacheable ✅

  • No request body (in practice)

Use cases

  • Fetch user profile

  • Retrieve blog articles

  • Product details

  • Download images

POST

Creates a new resource or triggers server processing.

POST /users

Characteristics

  • Safe ❌

  • Idempotent ❌

  • Usually not cacheable

Use cases

  • Create account

  • Upload files

  • Submit forms

  • Payment requests

PUT

Replaces an entire resource.

PUT /users/10

If the resource exists, replace it completely. If it doesn’t exist, many APIs create it.

Characteristics

  • Idempotent ✅

  • Not Safe ❌

PATCH

Updates only specific fields.

PATCH /users/10

Instead of replacing everything, update only what’s necessary.

Example

{
  "email":"[email protected]"
}

Perfect for partial updates.

DELETE

Deletes a resource.

DELETE /users/10

Simple and straightforward.

Works exactly like GET…

…but returns only headers.

Useful for

  • Checking file size

  • Cache validation

  • Availability checks

without downloading the actual content.

OPTIONS

Asks a server:

❝

“What operations do you support?”

Often used in

  • CORS

  • API discovery

  • Browser preflight requests

The Problem Developers Have Faced for Years

Imagine building a product search API.

Users can filter by

  • Category

  • Price

  • Brand

  • Ratings

  • Availability

  • Seller

  • Color

  • Size

  • Location

  • Shipping

  • AI similarity score

Your request might look like this:

{
  "category":"Laptop",
  "price":{
      "min":500,
      "max":1500
  },
  "brands":["Apple","Dell","Lenovo"],
  "rating":4,
  "available":true,
  "sort":"price",
  "page":1
}

Now ask yourself:

Should this be a GET request?

Not really.

GET expects parameters in the URL.

GET /products?category=Laptop&priceMin=500&priceMax=1500...

Eventually URLs become

  • Unreadable

  • difficult to maintain

  • limited in length

  • hard to generate

  • impossible for deeply nested objects

Developers then switched to POST.

POST /products/search

Problem solved? Not exactly.

POST implies

❝

“I’m creating or changing something.”

But searching doesn’t create anything. POST also loses important semantics.

Caching becomes harder. API documentation becomes confusing. Monitoring tools interpret POST differently. And REST purity disappears.

For years…

Developers had no perfect solution.

💡 Enjoying this article?
Every week day, I publish practical, production-ready deep dives covering Web development, System Design, Open source projects, Tech industry trends and AI Engineering and tools.

Subscribe to Newsletter

Meet HTTP QUERY

RFC 10008 introduces a new HTTP method:

QUERY /products

Its purpose is beautifully simple:

❝

Perform a query operation using a request body without implying resource creation or modification.

That’s exactly the missing piece HTTP had for years. Instead of squeezing data into URLs…

or pretending searches are POST requests…

We now have a method specifically designed for querying.

A Simple QUERY Example

QUERY /products
Content-Type: application/json

{
  "category":"Laptop",
  "price":{
      "min":500,
      "max":1500
  },
  "sort":"rating"
}

Response

[
   {
      "name":"MacBook Air",
      "price":1199
   }
]

Simple. Readable. Semantic. Correct.

Why GET Was Never Enough

Many developers ask:

❝

“Can’t GET already send a request body?”

Technically…

Some implementations allow it.

Practically…

HTTP never defined any meaning for GET request bodies. Many proxies ignore them. Some servers reject them.

Browsers behave inconsistently. Caching systems don’t understand them. This ambiguity made GET bodies unreliable.

QUERY officially solves this problem.

Why post Wasn’t the Right Solution

POST became the “everything else” method. Developers used it for

  • Search

  • reports

  • filtering

  • analytics

  • AI prompts

  • recommendation engines

But POST says

❝

“Process this request.”

not

❝

“Retrieve information.”

QUERY restores the missing semantics.

GET vs POST vs QUERY

This is why QUERY fills a gap instead of replacing GET or POST.

What Problems Does QUERY Actually Solve?

1. Complex Search APIs

Instead of

GET /employees?department=IT&salaryMin=50000...

you can send

QUERY /employees

with a structured JSON body.

2. Analytics Dashboards

Imagine Power BI or Grafana style filtering.

{
 "groupBy":"country",
 "from":"2026-01-01",
 "to":"2026-06-30",
 "metrics":[
   "sales",
   "profit"
 ]
}

Much cleaner.

Vector search often requires

  • embeddings

  • similarity thresholds

  • metadata filters

  • ranking options

QUERY handles these naturally.

4. Elasticsearch-style Queries

Search engines already use POST because GET is awkward. QUERY represents exactly what these systems are doing.

5. Business Intelligence APIs

Enterprise reporting often requires deeply nested request objects.

QUERY keeps them expressive while preserving correct HTTP semantics.

Why This Matters for REST APIs

REST isn’t only about URLs. It’s about communicating intent.

When someone sees

POST /search

they immediately wonder

“Is something being created?”

QUERY removes that ambiguity.

QUERY /search

Now the intent is crystal clear.

Important HTTP Semantics

RFC 10008 defines QUERY as a safe method.

Safe means

❝

It must not modify server state.

Exactly like GET.

That makes it suitable for

  • Searching

  • filtering

  • reporting

  • recommendations

  • AI inference requests

  • read-only analytics

without implying side effects.

Can QUERY Be Cached?

Yes, but differently from GET.

Because QUERY uses a request body, caches need a way to identify equivalent queries. RFC 10008 defines mechanisms such as returning a Content-Location header so that a query result can be associated with a retrievable URI. It also introduces the Accept-Query response header, allowing a server to advertise which media types it accepts for QUERY requests.

This gives intermediaries and clients enough information to cache and reuse responses safely while respecting the semantics of the request.

Does QUERY Replace GET?

No.

GET is still perfect for

  • Product pages

  • User profiles

  • Images

  • Articles

  • Static resources

QUERY exists for situations where the client needs to send a structured query that is too large or too complex for a URL, but where the operation is still read-only.

Does QUERY Replace POST?

Also no.

POST remains the correct choice when you need to:

  • Create a resource

  • Submit a form

  • Upload files

  • Trigger a payment

  • Execute operations that have side effects

QUERY is only for retrieving data.

Should You Start Using QUERY Today?

The specification is now official, but adoption takes time.

Web frameworks, browsers, reverse proxies, API gateways, SDKs, and cloud providers will gradually add support over the coming months and years. Until your infrastructure supports QUERY end-to-end, you’ll likely continue to see many search APIs implemented with POST.

However, understanding QUERY today prepares you for the future of HTTP API design.

Final Thoughts

HTTP has always excelled at expressing intent.

GET retrieves. POST creates. PUT replaces. PATCH updates. DELETE removes.

But there has always been one missing piece:

How do you retrieve complex data using a request body without pretending it’s a POST?

For nearly fifteen years, developers worked around this limitation with custom conventions, overloaded POST endpoints, and awkward query strings.

With RFC 10008, HTTP finally has a first-class solution.

QUERY isn’t just another HTTP verb — it fills a long-standing semantic gap and brings the protocol in line with the needs of modern APIs, AI-powered applications, analytics platforms, and enterprise search systems.

As support grows across frameworks and infrastructure, don’t be surprised if QUERY /search becomes as familiar as GET /users.

And when that happens, future developers may wonder why we ever overloaded POST for searching in the first place.

Reference: https://www.rfc-editor.org/info/rfc10008/

Thank You for Reading!

I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Your support and engagement mean a lot to me.

Happy Coding!

Reply

Avatar

or to participate

Keep Reading

View more
caret-right
© 2026 Vijayasekhar Deepak | FullStack JS & AI Newsletter.
beehiivPowered by beehiiv