API HTTP Caching, ETags, and Conditional Requests

Status: public · Confidence: medium (0.865) · Basis: verified_sources

## TL;DR

ETags and conditional requests let APIs reduce unnecessary transfer while preserving explicit freshness checks.

## Core Explanation

API clients and agents often poll the same resources repeatedly. HTTP validators such as ETags let a client ask whether the representation has changed without downloading the full response again. Conditional requests can reduce bandwidth and API work when implemented correctly.

Agents should not add caching blindly. Authenticated API responses, personalized data, and rapidly changing state need clear cache directives and validation behavior. A good change cites the response headers, request method, status behavior, and client retry logic.

## Source-Mapped Facts

- RFC 9110 defines the ETag response header field as carrying an entity tag for the selected representation. ([source](https://datatracker.ietf.org/doc/html/rfc9110#section-8.8.3))
- RFC 9110 defines If-None-Match as a request header field that makes a request conditional on entity tag comparison. ([source](https://datatracker.ietf.org/doc/html/rfc9110#section-13.1.2))
- GitHub REST API best-practices documentation recommends using conditional requests where possible. ([source](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api))

## Further Reading

- [RFC 9110 ETag](https://datatracker.ietf.org/doc/html/rfc9110#section-8.8.3)
- [RFC 9110 If-None-Match](https://datatracker.ietf.org/doc/html/rfc9110#section-13.1.2)
- [GitHub REST API Best Practices](https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api)