The RFC Editor recently published RFC 10008, which defines a new HTTP method called QUERY. This document was created by the Internet Engineering Task Force (IETF), a key group behind the internet’s main protocols, and was released as a Proposed Standard.
The new specification, called “The HTTP QUERY Method,” gives web developers and API designers a standard way to deal with complex read-only requests that need a request body. Simply put, it fills a gap between GET and POST.
Most people never see HTTP methods, but they work behind the scenes in browsers, apps, APIs, package managers, command-line tools, and web services. GET is used to request data, POST to send data, PUT and PATCH to update resources, and DELETE to remove them.
QUERY was created to solve a specific problem: what should an API use when it needs to send a complex query to a server, but only wants to get data without making any changes? Well, until now, developers had two main but imperfect options.
The first one was GET. It works well for simple queries, where you can put parameters right in the URL. For example, a feed request might include a keyword, a limit, and a sort order in the address. This method is simple, widely supported, and clearly read-only.
But GET can be awkward when the query is large, structured, or hard to fit into a URL. The RFC points out several issues: size limits might not be clear, some data is hard to encode in a URI, request URIs are more likely to be logged or bookmarked, and every combination of query inputs becomes a separate resource.
The second option was POST. Unlike GET, POST can carry a request body, so it’s often used when the client needs to send more complex data. This fixes the formatting issue, but creates a new problem: POST does not clearly show that the request is read-only. A POST request might create, update, trigger a job, submit a form, or just perform a search.
QUERY is meant to fill this gap. With it, the client puts the query in the request body, similar to POST. The key difference is that QUERY is clearly defined as safe and idempotent. In other words, QUERY is similar to GET in meaning, but to POST in how it carries request content.
The RFC says QUERY is a method where the server processes the content safely and idempotently, then returns the result. It also says QUERY requests can be repeated or restarted automatically without worrying about partial changes.
The new method also makes API design clearer. Instead of using POST for a read-only search just because GET is not flexible enough, developers now have a method that fits the operation more closely.
RFC 10008 also explains how QUERY fits into current HTTP behavior. Servers can show support for QUERY in the Allow response field, along with methods like GET, OPTIONS, and HEAD. The specification also introduces the Accept-Query response field, which lets a server say which query content formats it accepts.
Additionally, the document covers related topics like media types, caching, redirection, conditional requests, range requests, and security. For example, QUERY responses can be cached, and QUERY requests can be retried or repeated if needed, such as after a connection failure.
However, this is not something users should expect to work everywhere immediately. RFC 10008 is an Internet Standards Track document with Proposed Standard status, but adoption still depends on web servers, frameworks, proxies, clients, browsers, API platforms, and developer tools adding support where needed.
For additional details, here’s the announcement.
