HTTP QUERY: the method that was missing between GET and POST

After more than fifteen years of architectural compromises, the IETF is finally taking a formal step to address one of HTTP's historical gaps: the secure and efficient handling of complex searches.

With the introduction of the new HTTP QUERY method, complex requests and filters will no longer have to be crammed into the URL or sent via a non-safe method such as POST.

HTTP QUERY, a new method for REST architecture

The HTTP QUERY method is the first standard approved by the IETF since PATCH, introduced back in 2010. Although it is still far from widespread implementation, the QUERY method promises to solve one of the oldest dilemmas in REST architecture: how to send complex searches or filters without violating the rules of HTTP standards.

Until now, advanced searches had to be handled through compromises: neither GET nor POST, in fact, is an ideal solution.

The GET method requires data to be sent through parameters in the URL (which also has length limitations). However, including search parameters in the URL risks exposing sensitive data in server logs: filtering for a specific first and last name, for example, means making it visible in the logs. Having to use the URL also makes it impossible to execute complex queries, such as SQL queries or searches with advanced filters.

POST, on the other hand, solves the space limitations by placing the query in the body, but it is not a safe method. POST is designed to create or modify data, meaning to alter data on the server. It is therefore considered not idempotent: sending the same request multiple times using POST does not always produce the same result (as it does, for example, with GET or PUT).

The characteristics of the QUERY method

The new HTTP QUERY method solves the problem by combining two key characteristics: first, it sends the parameters in the request body without exposing them in the URL, like POST; second, it is an idempotent and cacheable method, like GET.

In summary, the QUERY method:

• Sends data in the body: it can therefore contain JSON, GraphQL, SQL-like syntax, or complex filters (without the space limitations of query strings) while keeping the URL clean;
• Is safe: it guarantees to the server and CDNs that the operation is read-only and will not modify the state of resources;
• Is idempotent: the same request returns the same result, allowing clients to perform automatic retries in the event of a network error;
• Is cacheable: proxies, CDNs, and browsers can store the response by generating a cache key based on the combination of URL and body.

QUERY, therefore, as described in RFC 10008 published by the IETF in June 2026, resolves an inconsistency that developers have been forced to deal with for years, combining the security and idempotency of GET with the structural ability to carry a highly detailed payload in the request body, as with POST.

The Content-Type in the QUERY method

According to the specifications defined by RFC 10008, when a body is present in a QUERY request, the Content-Type is also mandatory. The body can contain completely different formats, but the server and network components (such as proxies and CDNs) must know exactly how to interpret it before processing it or storing it in the cache.

The new standard introduces a “Accept-Query” response header, which tells the client which query formats the server is able to accept and process in the body of a request.

RFC 10008 also introduces the related error messages:

• 400 Bad Request: if the media type is missing or the body is syntactically incorrect;
• 415 Unsupported Media Type: if the format is not supported by the endpoint;
• 406 Not Acceptable: if the format requested in “Accept” cannot be provided;
• 422 Unprocessable Content: if the query is syntactically valid (e.g. valid JSON) but the data violates the application's business rules and therefore has no logical meaning for the server.

HTTP QUERY: the path to adoption of the new method

Widespread adoption of the QUERY method is expected approximately between 2027 and 2028. Before the new verb becomes a concrete standard in everyday operations, the entire software ecosystem will need to adapt: browsers, CDNs, and server frameworks will need to update their libraries to correctly recognize and handle the new method.

There are also still potential issues to address that will require adjustments to network security systems:

• Blind spots in firewalls: traditional web application firewalls (WAFs) inspect the message body only for methods that modify data (POST, PUT). By treating QUERY as a safe, read-only method, they risk ignoring the body, allowing attacks such as SQL Injection or XSS to pass through;
• Bypassing Anti-CSRF controls: Since QUERY is classified as a "safe" method, anti-CSRF middleware ignores it by default. If a developer incorrectly implements the endpoint so that it modifies data on the server, the application becomes vulnerable to CSRF attacks;
• Preflight: QUERY is not among the basic methods automatically authorized by browsers (safelisted). Requests from different domains will always require a preliminary control request (OPTIONS), potentially doubling network times.

In any case, the path toward implementing the QUERY method is now clear. From now on, the HTTP protocol will allow complex requests to be sent without modifying resources, combining the flexibility of POST with the read-only and reproducibility guarantees of GET.