GET: The Promise of Safety

GET's safety promise is the most economically valuable clause in HTTP, because it is what makes reads *speculative*. A browser can prefetch the next page, a CDN can serve a million users from one origin fetch, a client can retry a timed-out read without a moment's thought, a chat app can unfurl a pasted link — all because GET guarantees nobody is accountable for a state change. Remove the guarantee from one endpoint and every one of those actors becomes a potential attacker of your data, with no malice required.

Safety also makes GET the cacheable method. Everything in Caching as a Contract Clause and Conditional Requests: ETags, 304 and 412 — CDN offload, 304 revalidation, browser caches — applies only to requests that promise not to act. And safety composes with idempotency to make GET the *freely retryable* method: a timeout on a GET has exactly one correct client response, "try again", which is why read paths tolerate flaky networks so much better than write paths.

The promise is per-endpoint, not per-API: one unsafe GET poisons the assumptions for everything that touches it. And it is a promise about accountability, not byte-identity — logging the access, bumping metrics, warming a cache are fine. The test: if this request fired a thousand times by robots overnight, is any *domain* state different in a way anyone must answer for?

The classic dates to 2006 but re-occurs annually under new names: an admin panel exposes deletion as links — GET /deleteUser?id=42 — because links are easy to render. A crawler (or a browser prefetcher, or a link-checking plugin, or a security scanner) discovers the page and does what GET-speaking robots do: follows every link. Row by row, politely, with proper user agents, the database empties. No auth bypass occurred if the admin was logged in — the robot rode the session cookie (which is also the mechanics of CSRF: browsers attach cookies to GETs they are induced to make — see Cookies and Their Attributes).

Every actor behaved correctly except the API. The crawler is *entitled* to GET anything linked; the prefetcher is *entitled* to fetch what the user might click; the cache is entitled to serve the "response" of a mutation without invoking it — so the deletion sometimes silently *doesn't happen*, which is the same bug inverted. Blaming the robot misses the design lesson: GET's contract is what makes robots useful; an unsafe GET is a landmine placed on a public footpath.

GET's one structural weakness is that the request *is* the URL. Complex searches — a 40-clause filter tree, a vector similarity query, a report definition — blow past practical URL limits (~2KB in older proxies and some browsers) or demand encodings nobody can read or log safely. The pragmatic industry answer is a POST-shaped read: POST /search with the query in the body, explicitly documented as safe-in-effect despite the method (see Search Is a Different Contract Than Filtering).

Be honest about what that trade costs: HTTP-level caching is forfeited (intermediaries will not cache POST), retry middleware won't auto-resend, and the URL stops being shareable. Mitigate by keeping simple, common reads on GET (GET /products?category=shoes), reserving body-reads for genuinely complex queries, and — where result reuse matters — creating a named query resource (POST /searches → GET /searches/{id}/results), which restores cacheability and shareability at the cost of a two-step flow. What is *not* acceptable is the reverse smuggling: side effects hidden in GET because "it's just a read that also marks notifications seen". Split the read from the mark (see Resource or Action?); a read that acts is a lie in both directions.