Why can't an HTTP cache reuse a GraphQL response when every operation is POSTed to one URL?

## What an HTTP cache actually keys on Every HTTP cache — the browser's private store, a corporate forward proxy, a reverse proxy in your own datacentre, a CDN edge node — is a lookup table. The primary key is the **request method plus the target URI**. The response can narrow that key by listing request header names in `Vary`, so `Vary: Accept-Encoding` splits the entry into a gzip variant and an identity variant. That is the entire key space. Nothing in it is derived from the request body, and this is deliberate: the caching rules were written around a method whose semantics are "fetch the thing this URI names", where the URI *is* the identity of the thing. REST leans on that. `GET /arrays/AZ-14/inverters` names a resource; a cache can store the bytes under that URI and answer later readers without the origin ever hearing about them. Change the resource, change the URI, and the two entries never collide. ## Where GraphQL puts the discriminator GraphQL deliberately abandons resource URLs. There is one endpoint — conventionally something like `/graphql`, though the specification does not mandate a path — and the request body carries the executable document, the variables and optionally an operation name. That body is the *only* thing distinguishing one request from another. Take a solar-array telemetry graph. One screen sends: ```json {"query":"query SiteInverters($site:ID!){ site(id:$site){ inverters { id model } } }", "variables":{"site":"AZ-14"}} ``` Another sends: ```json {"query":"query StringOutput($s:ID!){ panelString(id:$s){ powerOutputKw lastReadingAt } }", "variables":{"s":"AZ-14-S07"}} ``` To the application these are unrelated reads of different data with different volatility. To a cache sitting between them they are the same key: `POST https://api.example.com/graphql`. The two responses have nothing in common, so an entry stored for the first would be a *wrong answer* to the second. A cache that served it would be broken, not merely inefficient. ## The three things this breaks **Shared caching is gone.** A CDN or reverse proxy in front of the endpoint sees one hot URI with wildly varying content and no safe way to split it. Every request travels to the origin. If ten thousand dashboards all ask for the same site summary in the same minute, the origin answers ten thousand times. **The browser cache is gone too.** The private cache in the user's browser follows the same rules; a POST result is not stored for reuse, so navigating back to a screen re-issues the request over the network. **Revalidation is gone.** Conditional requests are cheap because the client already holds a stored copy and a validator for it, and asks only "is this still current?". With nothing stored under the URI there is nothing to revalidate, so the endpoint pays full price for every read, including reads whose answer has not changed in hours. ## This is a consequence, not a bug It is worth saying plainly in an interview: nothing here is a defect in GraphQL, and nothing here is a defect in HTTP. It is the bill for a design trade. GraphQL bought precise, client-shaped responses and the removal of over- and under-fetching by giving up the property HTTP caching is built on — that the URI identifies the response. You cannot keep both for free. The volume of the bill depends on the traffic. An internal dashboard behind a login was never going to get shared-cache hits anyway, because its responses are per-viewer and a shared cache could not store them regardless of transport. A public, read-heavy, largely anonymous API is where the loss really hurts, and it is exactly where teams end up reaching for a way to put the operation back in the URL. ## What is still true The body being invisible to HTTP does not mean nothing anywhere caches. It means the *HTTP* tier cannot, and so caching migrates: into the client's own store, into the server's parsed-document and response caches, into the data layer behind the resolvers. Those tiers are real and often large. They are simply not addressable with a URL, not visible in a proxy's hit-rate metric, and not purgeable by the tooling an operations team already owns — which is the second half of the problem this endpoint shape creates. The recovery path, at a high level, is to make the operation part of the request line again: send the read as a GET whose query string carries the document (or a short identifier standing in for it) plus the variables, so the URI once more names the answer. That reopens the door — for reads only, and only for responses that are not per-viewer.