HTTP QUERY: The new method between GET and POST that could change the way we design APIs and caches

In the HTTP world, we have been accustomed for decades to reasoning around a few fundamental methods. GET to recover a resource, POST to send data to the server, PUT to update, DELETE to eliminate. This seemingly simple grammar underpins a huge part of the modern web: websites, REST APIs, mobile apps, SaaS services, microservices, reverse proxies, CDNs, and caching systems.

As applications have evolved, however, an increasingly evident grey area has emerged: how to properly manage the complex read-only queriesConsider a search with many filters, a GraphQL request, a reporting endpoint, a query with pagination, sorting, time ranges, and nested conditions. Semantically, the operation is a read: the server must return data, not modify it. So it would be natural to use GET. But from a practical standpoint, GET forces you to put everything in the URL, which presents length limitations, encoding issues, poor readability, and potential privacy implications for logs.

For years, the most common solution has been to use POST even for operations that were, in reality, simple queries. POST allows you to send a structured body, such as JSON, but it communicates a different meaning to the protocol: a request that could Modify the server's state. This detail isn't just theoretical. For caches, proxies, CDNs, WAFs, and HTTP clients, the method used is crucial information. Using POST to read data often means giving up some of the optimizations that HTTP already provides.

The new method HTTP QUERY, standardized with RFC 10008, was created precisely to fill this gap: it allows you to send a request with a body, like POST, but retains the properties of a read-only request, like GET. In other words, QUERY tells the server and intermediaries: "I'm executing a query, I can have a body, but I'm not asking to change the state of the resource."

The historical problem: GET is correct, but often insufficient

GET is the most natural HTTP method when we want to retrieve information. sure, because the client does not ask the server to change the state of the resource, and it is idempotent, because repeating the same request multiple times shouldn't produce different side effects. Furthermore, GET responses are easily handled by caches, browsers, reverse proxies, and CDNs.

The problem arises when the query becomes too complex. A request like this is perfectly manageable:

GET /prodotti?categoria=hosting&limit=10&sort=prezzo HTTP/1.1
Host: example.com

But what happens when you have dozens of filters, perhaps with nested conditions, arrays, dates, logical operators, full-text search, sorting preferences, and aggregation parameters? The URL becomes long, difficult to read, and more fragile throughout the delivery chain. Browsers, client libraries, enterprise proxies, load balancers, CDNs, and application firewalls can have different limitations and behaviors.

Then there is a topic that is often underestimated: URLs are logged very easilyThey end up in web server logs, reverse proxy logs, browser history, analytics tools, monitoring systems, or debugging dashboards. If the query contains sensitive data, even indirectly, including it in the query string isn't always the most prudent option.

Why POST has never been an elegant solution

POST solves the practical problem of the body. We can send complex JSON, a GraphQL query, an XML payload, or a custom application format without having to compress everything into the URL. For this reason, many modern APIs have used POST even for read-only operations.

The point is that POST doesn't convey the same semantics to the protocol as GET. A POST can create a resource, update a state, start a process, record an order, send a message, and produce permanent effects. When we use it simply to query data, the server knows this, the application client may know it, but HTTP intermediaries can't generally deduce it.

This means that Caching, automatic retry, proxy optimizations, and CDN strategies They become more complicated. An intermediate system can't assume that repeating a POST is harmless. It can't treat it with the same ease as a GET. As a result, many APIs that perform heavy reads end up always burdening the backend, even when the response would technically be reusable.

What does HTTP QUERY introduce?

QUERY introduces a simple but very powerful concept: a request can have a body, but remain read-only. The structure is similar to POST, but the semantics are different.

QUERY /api/search HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json

{
"q": "hosting linux managed",
"limit": 20,
"sort": "-created_at",
"filters": {
"status": "active",
"type": ["article", "service"]
}
}

With QUERY, the content of the request describes how to query the target resourceThe server processes the query and returns the result, without the client requesting a change in the resource's state. The RFC defines QUERY as a secure and idempotent method: two crucial properties for those designing reliable, scalable APIs that integrate well with the HTTP infrastructure.

However, QUERY should not be confused with a new data format. QUERY does not impose JSON, SQL, GraphQL, or JSONPath. The format is declared via Content-TypeThis makes the method flexible: each application can choose the most suitable query language, as long as the client and server agree on the meaning of the payload.

GET, POST, and QUERY Compared

The main difference is precisely this: QUERY combines the body of POST with the semantics of GETIt may seem like a subtle detail, but for those working on high-traffic APIs, microservices architectures, or distributed infrastructures, it can make a big difference.

The role of the Accept-Query header

The RFC also introduces the header Accept-Query, designed to allow a resource to declare which query formats it supports. This is a useful discovery mechanism because it saves the client from having to guess.

HTTP/1.1 200 OK
Allow: GET, QUERY
Accept-Query: application/json, application/graphql

In this example, the server declares that the resource accepts QUERY requests with JSON or GraphQL payloads. For a well-designed client, this information is invaluable: it allows it to choose the correct format, handle fallbacks, and produce clearer errors when the format is not supported.

The presence of Accept-Query is also interesting from an infrastructure perspective. In an environment consisting of API gateways, reverse proxies, and backend services, being able to explicitly declare support for query formats helps design cleaner contracts between the various components.

Cache and reverse proxy: where QUERY gets really interesting

The practical value of QUERY comes into its own when we talk about caching. A GET request is normally identified by its URI. With QUERY, however, a cache must also consider the content of the request and relevant metadata, such as Content-Type and other headers that influence the result.

This allows for multiple cacheable responses on the same endpoint, distinguishing them based on the query body. Two identical QUERY requests can be served from the cache; two different QUERY requests to the same endpoint must produce different cache keys.

For a modern infrastructure, this opens up interesting scenarios:

• application load reduction on research or reporting endpoints;
• better exploitation of reverse proxies and CDNs in front of read-only APIs;
• safer retries in case of temporary network errors;
• clearer semantics between client, gateway and backend.

Of course, simply having a standardized method isn't enough for everything to work immediately. Every element in the chain must recognize it, or at least forward it correctly: web servers, proxies, load balancers, CDNs, WAFs, application frameworks, and client libraries.

Beware of adoption: standardization does not mean immediate support

An important aspect is to distinguish between standardization e royal adoptionJust because QUERY has been defined as an RFC and registered by IANA doesn't mean that every browser, framework, CDN, or firewall already handles it optimally.

In real-world infrastructures, there are often explicit rules about permitted HTTP methods. A WAF might only allow GET, POST, HEAD, OPTIONS, PUT, and DELETE. A reverse proxy might have restrictive configurations. A legacy application might respond with an error to an unknown method. A logging system might not correctly classify the new request.

For this reason, QUERY should be considered a technology that should be carefully evaluated, especially in controlled contexts: server-to-server communications, internal APIs, test environments, microservices under the same operating domain, high-traffic search endpoints where clients and servers are managed by the same organization.

What this means for those managing hosting, Linux servers, and production APIs

From a systems perspective, QUERY isn't just a new feature for developers. It's a change that also affects those managing the infrastructure. If an application starts using QUERY, it's important to ensure that the entire chain is ready to receive and correctly forward the new method.

In a Linux environment with web servers, reverse proxies, and application firewalls, the main checks involve at least these aspects: Nginx or Apache configurations, WAF rules, CORS policies, logging, metrics, APM systems, load balancers, CDNs, and security tools. An unknown or not explicitly permitted HTTP method can be blocked before it even reaches the application.

It's also important to think about caching. If a reverse proxy or CDN starts caching QUERY responses, the cache key must include the request content and the correct metadata. Incorrect normalization could return incorrect results. Conversely, an overly conservative configuration could negate the benefits of the new method.

In other words, QUERY can be very useful, but it must be part of a thoughtful infrastructure design. It's not a simple "verb change" on the code side: it requires testing, observability, and consistent rules across the entire platform.

A practical example with curl

A client might send a QUERY request like this:

curl -X QUERY "https://api.example.com/search" 
-H "Content-Type: application/json" 
-H "Accept: application/json" 
--data '{
"q": "server managed linux",
"limit": 10,
"sort": "-published_at"
}'

From an application perspective, the server receives a structured payload. Semantically, however, the request isn't a generic POST: it's a secure and idempotent query. This is the core of the standard.

Will QUERY replace GET or POST?

No. QUERY wasn't created to replace GET or POST, but to address a use case that until now has been handled with compromises. GET remains perfect for simple requests, resources directly identifiable by URL, and easily cacheable content. POST remains the correct method when the client sends data that can create, modify, or trigger processing that impacts the server.

QUERY fits in between the two: it is suitable when we need to perform a complex query, with body, but read-onlyIt is therefore particularly interesting for search APIs, GraphQL, analytics endpoints, reporting, aggregations, and internal services that query large amounts of data without modifying it.

Conclusion

HTTP QUERY is an important new feature because it corrects a practical flaw that developers know well: using GET when the query doesn't fit comfortably within the URL, or using POST when it loses semantic clarity and infrastructure benefits. With QUERY, HTTP finally offers a method designed for complex, secure, idempotent, and cacheable queries.

For API developers, this means being able to design more consistent endpoints. For those managing Linux infrastructures, reverse proxies, CDNs, and managed environments, this means preparing to support a new HTTP method with appropriate configurations, tests, and policies.

As is often the case with standards, the impact won't be immediate. Adoption will require time, updates, and compatibility throughout the chain. But the direction is clear: QUERY makes HTTP more expressive, more correct, and more suitable for modern APIs.

At Managed Server, we closely monitor these developments because they directly impact the performance, security, caching, and reliability of web applications. A well-managed infrastructure doesn't just run a website or API: it must also be ready to securely and confidently adopt the standards that improve the web.