REST Cacheability and Cache-Control Headers

Cacheability in REST means a client cache or intermediary can store a response and reuse it when HTTP rules allow. Reusing a response can reduce latency, bandwidth, and work at the origin service. It is different from an internal Spring or database cache because HTTP metadata tells components outside the application whether the transferred response is safe to retain and reuse.

Cache-Control carries the main policy. max-age=60 normally makes a stored response fresh for 60 seconds. no-cache permits storage but requires validation before reuse, while no-store tells caches not to store the response. private limits storage to a private cache such as a browser; public explicitly permits shared-cache storage in cases where that policy is appropriate.

The origin can return an opaque validator such as ETag: "product-42-v7". After the response becomes stale, the client sends If-None-Match: "product-42-v7". If the selected representation is unchanged, the origin returns 304 Not Modified without another response body, and the cache reuses its stored copy. Last-Modified with If-Modified-Since provides a time-based alternative with lower precision.

A public product catalogue may use shared caching, while an account response usually needs private or no-store according to its sensitivity. Vary names request headers that selected the representation. For example, Vary: Accept-Encoding keeps compressed and uncompressed responses in separate cache entries. Missing Vary can serve the wrong variant; naming too many fields can reduce the cache hit rate.

A cache rule must reflect how stale the data may be, who may receive it, and which request selected it. Statelessness alone does not make a response cacheable, and a framework cache annotation does not create a correct HTTP contract. Test the actual method, status, headers, mutation path, and revalidation response. Fast reuse is useful only when the cache cannot leak personalized data or return an unacceptable old representation.