HTTP QUERY becomes a Proposed Standard: goodbye to POST for complex queries? 🌐

The IETF has officially granted the new HTTP method QUERY “Proposed Standard” status. This means the concept is considered mature, the specification is stable, and widespread adoption is the next step.

What problem does QUERY solve? We have all run into the limitations of GET. When you need to send the backend a complex search query with lots of filters, sorting options and nested structures, you hit two problems: 1. URL overflow: You quickly run out of room within query-string length limits. 2. Security and logs: Personal data, tokens or sensitive filtering parameters in GET queries show up in server logs, browser history and proxy servers.

How did we work around this before? That’s right: we used POST. But according to the specification, POST is neither safe nor idempotent: it is intended to change a resource’s state. As a result, browsers and caching proxies do not cache POST requests by default. We had to reinvent the wheel with custom caching or put up with the network overhead.

What does QUERY do? It combines the best of both worlds: — A request body: Like POST, QUERY can carry a full payload (JSON, GraphQL or SQL-like syntax) in the request body, taking the load off the URL. — GET semantics: The method is officially safe and idempotent. It changes nothing on the server, so its responses can be cached natively by CDNs and the browser’s HTTP architecture. Essentially, QUERY is what GET should have been for complex selections from the start.

The specification release on the IETF website

What do you think of the update? Are you waiting for native support in your frameworks and servers, or is good old POST for search already ingrained? Have you encountered URL overflow in real projects, and how did you get around it: split the requests or immediately give in to POST? 👇