HTTP QUERY: the immediate future of API queries

A new way to carry complex queries without turning the URL into a puzzle or presenting a read operation as if it were a write.

What happens when a query needs filters, rules, lists, and pagination, but must not change anything at all?

For years, the usual answer involved choosing between two imperfect paths. The first was to place every criterion in the URL of a GET request. The second was to send a request body with POST, even though the real intention was only to retrieve information. HTTP QUERY is designed to fill that gap: a query can carry structured content while explicitly declaring that it is safe and idempotent.

This is not a replacement for GET. GET remains an excellent choice for simple searches, shareable addresses, and clearly identifiable resources. QUERY is aimed at a different situation: advanced filters, configurable reports, catalog exploration, analytics, enterprise search, and requests whose criteria no longer fit comfortably in a URL.

GET is not the problem; the problem is what we ask it to carry

GET works beautifully when a query is small: an identifier, a search term, a page number, or a few filters. The difficulty begins when a visual interface lets users combine brands, categories, ranges, states, sorting rules, selected fields, and dozens of conditions.

At that point, a URL can grow into something that is difficult to read, log, copy, and maintain. Every intermediary — browser, proxy, load balancer, server, or security tool — may also impose a different limit. RFC 10008 notes that these limits are not always known in advance and that encoding rich structures into a valid URI adds overhead.

There is also an exposure concern. URLs commonly appear in histories, bookmarks, analytics tools, access logs, and observability dashboards. This does not make QUERY a privacy mechanism — request content still requires proper protection and governance — but it avoids placing the entire search definition directly in the visible address.

Why not keep using POST?

Many APIs already solve complex searches with routes such as POST /search. That is a pragmatic solution and it will remain necessary for years. However, an intermediary that sees only the method cannot know whether that POST creates something, starts a process with side effects, or performs a query that could safely be repeated.

QUERY makes that intention visible at the protocol level. Infrastructure can recognize a safe, idempotent operation; a client can consider retrying it; and a documentation tool can classify it as a query without relying on a private convention. The proposal does not invent a new filter language. It provides a clearer way to express what the request means.

In the official abstract, QUERY processes enclosed content “in a safe and idempotent manner.” That short phrase is the center of the entire design.

A small demo because the ecosystem is only getting started

To explore this immediate future, the Demo_http_query project was created with PowerBuilder 2025 R2 and a local ASP.NET Core API. During preparation of the demo, we did not identify a widely documented public API exposing a QUERY endpoint that would be suitable for a reproducible demonstration. A small, controlled API was therefore built around an in-memory product catalog.

The window builds one query and sends it as GET, POST, or QUERY. It also uses OPTIONS to discover supported methods and the Accept-Query header to advertise the accepted format. The response is displayed as a navigable JSON tree, making the difference between methods visible without hiding the result behind a console.

The experiment confirms another important point: server support alone is not enough. The client, runtime, proxy, and every tool in the path must allow the method to pass. PowerBuilder 2025 R2 transmitted it through HTTPClient.SendRequest("QUERY", ...), while ASP.NET Core received it through a route explicitly associated with the method.

The most visible advantages

RFC 10008 also covers features that make QUERY more than “POST with a different name”: discovery through OPTIONS, formats advertised with Accept-Query, cacheable responses, conditional requests, and the possibility of assigning a URI to either a query or its result.

The challenges of adding QUERY to existing APIs

The existence of a standard does not make adoption instantaneous. New HTTP methods are rare because they cross many layers that have spent years being configured around GET, POST, PUT, PATCH, and DELETE.

• Gateways and firewalls: method allowlists may reject QUERY until policies are updated.
• Clients and SDKs: code generators and closed method enumerations may not recognize it yet.
• CORS: browser-based QUERY requests require preflight because QUERY is not a CORS-safelisted method.
• Caching and observability: platforms must learn how query content affects result identity, metrics, and traces.
• Documentation: OpenAPI descriptions, portals, automated tests, and internal policies need a clear representation of the method.
• Gradual compatibility: keeping GET or POST as a fallback will be reasonable during migration.

A sensible adoption path: begin with the difficult cases

The best approach is unlikely to involve converting every existing GET endpoint. A careful adoption can begin where current limitations are already obvious: enterprise search engines, dynamic reports, analytical queries, geospatial filters, large catalogs, and event explorers.

In those cases, an API can advertise QUERY through OPTIONS and Accept-Query, temporarily retain a compatibility POST endpoint, and measure which intermediaries require adjustment. The change can be incremental, observable, and reversible.

Conclusion: a new word for an intention that already existed

Applications have been sending complex queries for years. What is new is not the need, but the ability to express it directly within HTTP. GET will remain the simplest and most universal retrieval method. POST will remain the broad mechanism for processing. QUERY offers a dedicated space for structured query content without giving up the safe and idempotent semantics expected from a read operation.

The immediate future will depend less on the elegance of the RFC than on how quickly servers, proxies, SDKs, browsers, and observability platforms learn to recognize it. The PowerBuilder demo shows that teams can begin experimenting with that future today in a small, visible, and controlled environment

See demo on CodeXchange

Official sources

• RFC 10008 — The HTTP QUERY Method
• IANA — HTTP Method Registry
• RFC 9110 — HTTP Semantics
• RFC 9205 — Building Protocols with HTTP     
•  

Luis Avilan