HTTP QUERY Is Finally Here: Here's Why It Matters More Than You Think

Table of Contents

• Introduction


• 
  The Long Road From GET to QUERY
  
  
  
  
  • HTTP/0.9
  
  
  • HTTP/1.0
  
  
  • HTTP/1.1
  
  
  
  


• 
  The HTTP Semantics That Absolutely Matter
  
  
  
  
  • Safety and Idempotence: The Foundations of HTTP Semantics
  
  
  • Safety
  
  
  • Idempotence
  
  
  • Pizza Explains Everything
  
  
  • Safety and Idempotence Table (Before QUERY)
  
  
  
  


• 
  Enter HTTP QUERY
  
  
  
  
  • Why Do We Need Another HTTP Method?
  
  
  • HTTP QUERY for the Win
  
  
  • How Do Clients Know a Server Supports QUERY?
  
  
  • Giving a Query a URI
  
  
  • A Few Things to Watch Out For
  
  
  
  


• 
  Personal Take
  
  
  
  
  • A Step in the Right Direction
  
  
  • Don't Rush
  
  
  • GraphQL
  
  
  
  


• Conclusion

Introduction

I've been waiting for this for a long time. Not because HTTP is broken, but because there has always been a subtle but awkward gap in the protocol. A gap that developers have been working around for years, usually by stretching GET a little too far or by reaching for POST even though its semantics never quite fit read-only queries.

Every time I had to squeeze one more filter into a GET request or use POST for something that was obviously just fetching data, a voice in my head kept saying:

"There has to be a better way."

And boy, do we have a better way now... finally!

HTTP QUERY fills that gap.

And this is no longer just an interesting proposal floating around the internet. In June 2026, it was officially published as in 1996, the protocol introduced a richer request and response model, including status codes, headers, and two new methods alongside GET: HEAD and POST. Interestingly, PUT and DELETE appeared only in an appendix of RFC 1945 as "Additional Request Methods", they weren't part of the core specification yet.

HTTP/1.1

Then HTTP/1.1, standardized through (1999), formally defined PUT, DELETE, OPTIONS, and TRACE, refined the semantics of all methods, and established principles that still define HTTP today. PATCH arrived later through (2014) and consolidated in

The key idea is that the client is asking to retrieve information, not to modify the application's business state.

In other words, incidental changes to operational state can be acceptable. Making a business-state change the purpose of a safe request is not.

Idempotence

Idempotence means that making the same request multiple times has the same intended effect on the server as making it once. Methods such as GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are idempotent by definition, while POST and PATCH are not guaranteed to be.

Before the "Actually" Squad Arrives Again...

Just like with safety, there are some important exceptions and nuances.

Idempotence does not mean that every repeated request produces the exact same response. The server is allowed to return different responses each time.

For example:

DELETE /users/42

The first request might return:

204 No Content

Because the user was successfully deleted.

The second request might return:

404 Not Found

Because the user no longer exists. (Some might argue that the service should return 204 No Content even when the resource has already been deleted, but that discussion needs a separate article.)

The operation is still considered idempotent because the intended result is the same: after the request completes, the user is gone.

Idempotence also does not mean that the server has no side effects. A repeated PUT or DELETE request may still create logs, update metrics, or trigger internal processing. These are incidental effects, not changes to the intended resource state.

The important question is not:

"Did absolutely nothing happen twice?"

The question is:

"Did repeating the same request produce the same intended state?"

That distinction is what allows HTTP infrastructure to safely retry certain requests when needed.

Pizza Explains Everything

A good pie of pepperoni pizza is the answer to everything in this world. This topic is no exception.

Imagine ordering your favorite pizza.

A safe operation is asking the pizza place: "What pizzas do you have?" You get information, but nobody starts cooking anything.

An idempotent operation is telling them: "Replace my order with one large pepperoni pizza." If your phone accidentally sends the request five times, the result is still one large pepperoni pizza.

...Now I want some pizza.

Safety and Idempotence Table (Before QUERY)

Enter HTTP QUERY

Why Do We Need Another HTTP Method?

Alright, enough with the prerequisites. Let's finally talk about HTTP QUERY.

As the name suggests, the QUERY method is designed for querying resources... duh.

Imagine you're building a large airport management system. It obviously has a vast number of data points and supports hundreds, if not thousands, of filtering options.

If all you need is the basic information for a specific flight, a simple GET request is exactly the right choice:

GET /flights/BA217 HTTP/1.1

Host: api.airport.example

Accept: application/json

The server might respond with:

HTTP/1.1 200 OK

Content-Type: application/json

Cache-Control: max-age=60



{

  "flightNumber": "BA217",

  "origin": "LHR",

  "destination": "IAD",

  "status": "Boarding",

  "gate": "A12"

}

Nothing fancy here. Just a good old HTTP GET request.

Now, let's say you're not looking for one specific flight anymore. You want to build an operations dashboard that shows all flights matching certain conditions.

For example:

• Flights departing from London Heathrow (LHR)


• Arriving at Washington Dulles (IAD)


• Between 6:00 PM and 10:00 PM


• Currently delayed


• Operated by British Airways


• With at least 200 passengers


• Sorted by delay duration


• Returning only the first 50 results

A GET request might become:

GET /flights?origin=LHR&destination=IAD&departureStart=18:00&departureEnd=22:00&status=delayed&airline=BA&minPassengers=200&sort=delayDuration&page=1&limit=50 HTTP/1.1

Host: api.airport.example

Accept: application/json

This is a very realistic example of what a request like this might look like. At first glance, everything seems perfectly fine, and theoretically, there shouldn't be any issues. And for simple cases, that's absolutely true.

However, things start to change in the real world. Once a query becomes too large or too complex, this approach begins to break down.

There are several reasons for this:

• 
  URI length limits are unpredictable: A request can pass through many systems: browsers, proxies, gateways, and servers, each with their own limits. The sender often cannot know the maximum supported size in advance.


• 
  Some data is inefficient to encode in a URI: Complex filters, nested conditions, sorting rules, and other structured data become difficult to represent and maintain once everything has to be serialized into a URL.


• 
  URIs are more exposed than request bodies: URLs are commonly stored in logs, browser history, analytics tools, and bookmarks, which makes putting large or sensitive query data inside them undesirable.


• 
  Every query representation becomes a distinct URI: Different parameter orderings or serializations can create distinct resource identifiers even when they express the same logical query. This can fragment monitoring data and make one logical operation appear as many different request targets.

I actually ran into a similar problem myself years ago while working with an API that required advanced sorting and filtering.

I tried to follow HTTP conventions and use GET, which seemed like the right approach at first. After all, I was only retrieving data, so GET was the obvious choice.

But as the number of filters, sorting options, and query parameters kept growing, the query strings started becoming massive.

Eventually, they got so large that the server basically looked at my request and said: "Nah, I ain't processing that."

And just like everyone else in this situation, I went with the most common workaround.

I am deliberately emphasizing the word workaround here because it is not the same thing as a proper solution. A solution addresses the underlying problem in the way the system was designed to work. A workaround simply gets the job done, but it may come with trade-offs and doesn't necessarily follow the original conventions.

And that workaround? HTTP POST.

Let's talk about why POST isn't the best tool for the job either.

Technically, it works. You can simply put your large, complex query inside the request body of a POST request, process it on the back end, and move on. Easy!

The request would look like the following:

POST /flights/search HTTP/1.1

Host: api.airport.example

Accept: application/json

Content-Type: application/json



{

  "origin": "LHR",

  "destination": "IAD",

  "departureStart": "18:00",

  "departureEnd": "22:00",

  "status": "delayed",

  "airline": "BA",

  "minPassengers": 200,

  "sort": "delayDuration",

  "page": 1,

  "limit": 50

}

But here's the catch. Well, actually, there are several catches.

The first catch is caching

Unlike GET, POST responses are not reusable by caches in the usual way. HTTP does allow a POST response to be cached when it includes explicit freshness information and a Content-Location matching the POST request's target URI, but that cached response can be reused for later GET or HEAD requests, not another equivalent POST request. Most browser caches, CDNs, and proxies do not implement this pattern automatically anyway.

For complex queries, this can be a significant limitation. These requests often involve expensive filtering, sorting, database operations, or aggregations, and caching repeated results can save substantial processing time and improve performance.

Of course, you can implement custom caching on top of POST. However, now you need to solve additional problems yourself, such as creating reliable cache keys, handling invalidation, and ensuring that cached responses correctly match the original request.

Another reason why POST is not an ideal fit for these operations comes down to the semantics of the method itself

Remember what we discussed earlier about HTTP methods? POST is defined as neither safe nor idempotent. It is intended for submitting data to be processed, often resulting in some kind of state change.

A query operation is fundamentally different. When we are retrieving data, we are performing a read-only operation. We generally want it to be safe, repeatable, and compatible with HTTP's caching mechanisms.

The semantics of POST do not provide those guarantees. Along with methods like PATCH, it is simply not the natural semantic fit for this type of operation.

So why is it still commonly used for complex queries? Because POST is widely supported, familiar, and flexible. When developers hit the limitations of GET, POST becomes the obvious workaround, even if it is not the perfect tool for the job.

Think about it

If we can use POST for querying data, why can't we use PUT or DELETE instead? After all, they are idempotent, so on paper they might seem like better candidates.

But that still wouldn't make much sense.

Idempotence alone does not mean a method is suitable for reading data. PUT and DELETE are still designed for operations that modify resource state, replacing or removing resources respectively. They simply guarantee that repeating the same operation produces the same intended result.

POST became the common workaround not because it is the perfect fit, but because it is flexible, widely supported, and allows clients to send complex data in the request body. Over time, using POST for complex queries became such a common pattern that it started feeling natural, even though it doesn't perfectly match the semantics of a read-only operation.

GET with a request body?

Some of you might ask the following question: instead of using POST, why don't we just use GET? After all, the HTTP message format can technically carry content with a GET request, just like it can with POST, right?

Well, yes, at the message-format level, that is possible. But HTTP does not define generally applicable semantics for content in a GET request. In other words, you can send it, but there is no universal agreement about what anyone should do with it.

But as we've already seen several times, theory and real-world behavior are not always the same thing. Reality hits us with a left hook. Many existing systems, including some servers, proxies, and CDNs, do not reliably handle GET request bodies. Some may ignore them, reject them, or just not forward them as expected.