HTTP caching temporarily stores responses so later requests can avoid repeated retrieval and data downloads. It improves response time, battery usage, data consumption, and provider efficiency, but stale data can mislead users. section 13.0 section 13.4.1
Define caching policies from the data’s volatility, composition, and usage context rather than leaving consumers to choose. Sensitive or accuracy-critical responses may require no storage, while other responses can specify a freshness period. section 13.4.2 section 13.9
Use standard response metadata to make cache behavior interoperable:
- Use Cache-Control: no-store when a response must not be cached. section 13.4.4
- Use max-age to specify how many seconds a response may remain cached. section 13.4.4
- Use no-cache when caching is allowed but validation is required before reuse. section 13.4.4
- Use Vary when content negotiation changes the representation, so formats or languages receive distinct cache keys. section 13.4.4
Bank account details
A banking application caches GET /accounts/123 for 10 minutes, avoiding repeated calls during navigation. Because a transaction can change the balance, it validates the cached representation with If-None-Match and the previous ETag. The server returns 304 Not Modified without a body when unchanged, or 200 OK with updated data and a new ETag when modified. section 13.4.1 section 13.4.5
Figure 13.7 The Cache-Control response header contains directives indicating whether and how the returned data can be cached.
Use the Cache-Control directive diagram to compare storage, freshness, and validation behavior. section 13.4.4
Figure 13.8 The If-None-Match header allows us to return data only if it has changed compared to the provided Etag value.
Use the conditional-request diagram to trace ETag validation and the 304 Not Modified path. section 13.4.5
