The QUERY Method

After years of discussion, the IETF HTTP working group published RFC 10008, defining the QUERY method for HTTP. The pitch is simple: it uses GET semantics (safe, idempotent, cacheable) with a request body. No more cramming complex filter parameters into a URL, and no more pretending a POST is read-only.

Kreya’s writeup covers the history well. This post is focused specifically on what QUERY changes for embedded and IoT deployments, where the tradeoffs between GET and POST have always been more painful than they are in web development.

What Changed

HTTP method comparison chart showing GET, POST, and QUERY across request body support, safety and idempotency, auto-retry safety, cacheability, and complex query handling

Why This Is Different For IoT

In web development, the choice between GET and POST is mostly a style debate. In embedded systems it is not. Cellular links drop, Wi-Fi cuts out mid-transmission, and your device might be running on a coin cell with strict duty cycles. These constraints make the semantic properties of HTTP methods matter in ways they simply do not in a browser.

The three concrete wins for IoT are auto-retry safety, cleaner complex queries, and fleet-scale caching. Let me walk through each.

HTTP client libraries treat safe, idempotent methods as automatically retriable on connection failure. QUERY gets that treatment. POST does not.

Previously, if your CMP4020 needed to send device state as a body to query a config endpoint, you used POST and had to write your own retry logic to avoid triggering side effects twice. With QUERY, the stack already knows it is safe to retry.

Side by side comparison of POST and QUERY retry behavior on a dropped connection, showing manual application-level decisions for POST versus automatic safe retries for QUERY

2. Complex Device Queries Without URL Hacks

A device often needs to ask the server something specific: “Given my firmware version, hardware revision, region, and current sensor calibration, what config should I be running?” That turns into a 400-character URL. Many proxies, load balancers, and HTTP stacks on constrained hardware have URL length limits somewhere between 512 bytes and 2KB.

The CMP4020 running our embedded HTTP stack hits this in practice when querying config endpoints with rich device context. QUERY puts that where it belongs: in the body.

Before and after comparison showing a long fragile config URL with query parameters versus a clean structured QUERY request with a JSON body This also matters for OTA update checks, where devices need to send their full manifest to ask what updates apply. That is a natural fit for QUERY: it is a read operation with structured input, and it is safe to retry if the link drops mid-request.

3. Fleet-Scale Caching

POST responses cannot be cached by CDNs or intermediary proxies. QUERY responses can, with the request body factored into the cache key. If you have thousands of devices asking identical or near-identical questions (firmware update checks, config pulls, rule engine queries), this meaningfully reduces server load at scale.

Illustrative diagram of 1,000 devices issuing the same query, showing 1,000 origin hits with POST versus roughly 3 origin hits with QUERY once the CDN cache is warm

…Unfortunately

QUERY is brand new. No mainstream web servers (nginx, Apache, Caddy) support it natively yet. Adoption will take years before you can assume middleware in the path handles it correctly.

On the client side this is a non-issue. For most of our devices, the HTTP stack does not care what the method string is. The server side requires a custom handler today, or a framework that lets you register arbitrary methods.

Also worth saying, QUERY does not touch server push or pub/sub. If your use case is the server pushing data to devices asynchronously, QUERY is irrelevant. That is WebSockets, SSE, or MQTT’s domain.

QUERY’s value is specific. Device-initiated reads with complex parameters: config pulls, OTA checks, rule engine queries. If that pattern exists in your system, QUERY simplifies it cleanly. Everything else stays the same.

What to Watch For

Keep an eye on nginx and Caddy changelogs. First-class QUERY support there will be the signal that adoption has tipped. On the embedded SDK side, watch for QUERY to appear as a named constant in your HTTP client library rather than a custom string. That is when it becomes official in your toolchain.

In the meantime you can prototype today with any framework that accepts custom HTTP methods. Most do. The spec is stable, the RFC is published, and the semantics are solid. For new endpoints that are read-only with body requirements, there is no reason not to use it now.

Further Reading