Concept and mechanism
Caching can reduce latency and load but needs policy consistent with content and audience. no-cache permits storage subject to validation before reuse; no-store instructs a cache not to retain content without guaranteeing all system privacy by itself. private distinguishes shared from private caches. None of these directives should replace authorization or encryption. When diagnosing an old response, collect headers and identify the layer that served it. Correct service configuration may be changed by a proxy, so observation should follow the effective path.
Guided application
In a fictional scenario, a positions report reaches the wrong client after being served by shared cache. Stop inappropriate reuse, preserve evidence, and review policy and identity separation of responses. For collection listing, define pagination and ordering stability. A cursor is not automatically a consistent snapshot or an authorization token. Google AIP 158 guidance illustrates opaque tokens for continuing a listing while retaining authorization on each request. Document what happens when new records arrive between pages, which filters must remain unchanged, and when cursors expire. A short page does not establish completion if the contract provides continuation.
Caches and cursors are delivery mechanisms; they do not transfer permissions between users.
Common pitfalls
No-cache as no storage; private as encryption; cursor as authorization; short page as universal completion.
Related topics: API resources and contracts · Requests and outcomes · Concurrency and retries
Validate audience, freshness, and continuation according to the contract.
Reference: RFC9111 HTTP Caching · HTTP semantics RFC9110; OpenAPI3.2.1; selected primary standards and provider contracts consulted2026-09-30