HTTP caching retains a response or resource copy so later access can avoid another retrieval or request. It improves convenience and reduces repeated work, but every copy creates a freshness and consistency decision. section 13.3.3 section 26.3.2
Choose the cache boundary deliberately:
- Cache a related resource inside another resource when avoiding a second API call matters; then define how the embedded copy stays current. section 13.3.3
- Use a live reference when freshness is more important than convenience; clients must make another request to retrieve the referenced resource. section 13.3.3
- For request deduplication, cache the complete response under its request identifier after processing the request, then return it for repeats. section 26.3.2
- Prefer a straightforward response cache over recalculating results, while setting expiration and invalidation deliberately and accounting for large responses. section 26.3.2 section 26.6
Books and authors
A client can retrieve a book and then issue a second request for its author name. Embedding the Author object in the Book response removes that extra call, but the server must either join current author data for every request or maintain a cached author copy. If the author changes, the embedded value requires a freshness strategy. section 13.3.3
