129 lines
6.1 KiB
Plaintext
129 lines
6.1 KiB
Plaintext
# Example HTTP Headers for API Caching
|
|
|
|
This document provides example HTTP headers that you can use to implement caching strategies for your API. These headers can be configured on your server to instruct browsers, CDNs, and other caching proxies on how to cache your API responses.
|
|
|
|
## Cache-Control
|
|
|
|
The `Cache-Control` header is the primary mechanism for controlling caching behavior. It allows you to specify various directives related to caching.
|
|
|
|
### Common Directives
|
|
|
|
* **`public`**: Indicates that the response can be cached by any cache (e.g., browser, CDN, proxy).
|
|
* **`private`**: Indicates that the response can only be cached by the user's browser and not by shared caches.
|
|
* **`max-age=<seconds>`**: Specifies the maximum amount of time (in seconds) that a response is considered fresh. After this time, the cache must revalidate the response with the origin server. **[Insert your desired cache duration in seconds here]**
|
|
* **`s-maxage=<seconds>`**: Similar to `max-age`, but specifically for shared caches like CDNs. This overrides `max-age` for shared caches. **[Insert your desired CDN cache duration in seconds here]**
|
|
* **`no-cache`**: Forces caches to revalidate the response with the origin server before using it. The cache can still store the response, but it must always check for updates.
|
|
* **`no-store`**: Indicates that the response should not be cached at all.
|
|
* **`must-revalidate`**: Instructs caches to strictly adhere to the freshness information provided in the response. If a cached response is stale, the cache must revalidate it with the origin server before using it.
|
|
* **`proxy-revalidate`**: Similar to `must-revalidate`, but specifically for proxy caches.
|
|
|
|
### Example Cache-Control Headers
|
|
|
|
* **For public caching with a 1 hour (3600 seconds) TTL:**
|
|
|
|
```
|
|
Cache-Control: public, max-age=3600
|
|
```
|
|
|
|
* **For private caching with a 5 minute (300 seconds) TTL:**
|
|
|
|
```
|
|
Cache-Control: private, max-age=300
|
|
```
|
|
|
|
* **For CDN caching with a 1 day (86400 seconds) TTL and browser caching with 1 hour:**
|
|
|
|
```
|
|
Cache-Control: public, max-age=3600, s-maxage=86400
|
|
```
|
|
|
|
* **To force revalidation:**
|
|
|
|
```
|
|
Cache-Control: no-cache
|
|
```
|
|
|
|
* **To prevent caching:**
|
|
|
|
```
|
|
Cache-Control: no-store
|
|
```
|
|
|
|
## Expires
|
|
|
|
The `Expires` header specifies an absolute date/time after which the response is considered stale. While still supported, `Cache-Control` is generally preferred as it offers more flexibility.
|
|
|
|
### Example Expires Header
|
|
|
|
* **Expires one week from now:**
|
|
|
|
```
|
|
Expires: [Insert calculated date/time string for one week from now in HTTP date format (e.g., "Tue, 15 Nov 2024 08:12:31 GMT")]
|
|
```
|
|
|
|
## ETag
|
|
|
|
The `ETag` header provides a unique identifier for a specific version of a resource. The server generates this value, and the client can use it in subsequent requests with the `If-None-Match` header to perform conditional requests.
|
|
|
|
### Usage
|
|
|
|
1. The server returns an `ETag` header with the initial response. **[Insert example ETag value here]**
|
|
2. The client stores the `ETag` value.
|
|
3. When the client needs to request the same resource again, it includes the `If-None-Match` header with the stored `ETag` value.
|
|
4. If the resource has not changed since the client last requested it, the server returns a `304 Not Modified` response. If the resource has changed, the server returns the new resource with a new `ETag` value.
|
|
|
|
### Example ETag Header
|
|
|
|
```
|
|
ETag: "[Insert generated ETag value here]"
|
|
```
|
|
|
|
## Last-Modified
|
|
|
|
The `Last-Modified` header indicates the date and time the resource was last modified on the server. Clients can use this information with the `If-Modified-Since` header to perform conditional requests.
|
|
|
|
### Usage
|
|
|
|
1. The server includes the `Last-Modified` header with the initial response. **[Insert Last-Modified date/time string here]**
|
|
2. The client stores the `Last-Modified` value.
|
|
3. When the client needs to request the same resource again, it includes the `If-Modified-Since` header with the stored `Last-Modified` value.
|
|
4. If the resource has not been modified since the client last requested it, the server returns a `304 Not Modified` response. If the resource has been modified, the server returns the new resource with an updated `Last-Modified` value.
|
|
|
|
### Example Last-Modified Header
|
|
|
|
```
|
|
Last-Modified: [Insert date/time string in HTTP date format (e.g., "Mon, 14 Nov 2024 10:00:00 GMT")]
|
|
```
|
|
|
|
## Vary
|
|
|
|
The `Vary` header specifies the request headers that the server uses to determine which version of a resource to serve. This is important when the server returns different responses based on the client's request headers (e.g., language, user-agent).
|
|
|
|
### Example Vary Header
|
|
|
|
* **Vary based on the `Accept-Language` header:**
|
|
|
|
```
|
|
Vary: Accept-Language
|
|
```
|
|
|
|
* **Vary based on the `User-Agent` and `Accept-Encoding` headers:**
|
|
|
|
```
|
|
Vary: User-Agent, Accept-Encoding
|
|
```
|
|
|
|
* **Vary on everything (use with caution as it can reduce cache effectiveness):**
|
|
|
|
```
|
|
Vary: *
|
|
```
|
|
|
|
## Practical Considerations
|
|
|
|
* **Balancing Freshness and Validation:** Carefully consider the `max-age` and `s-maxage` values to strike a balance between serving cached content and ensuring that clients receive up-to-date information.
|
|
* **CDN Configuration:** Configure your CDN to respect the caching headers set by your origin server. Refer to your CDN provider's documentation for specific instructions.
|
|
* **Testing:** Thoroughly test your caching configuration to ensure that it is working as expected and that clients are receiving the correct responses. Use browser developer tools or command-line tools like `curl` to inspect the HTTP headers.
|
|
* **API Design:** Design your API to be cache-friendly. For example, use resource-based URLs and provide appropriate `ETag` or `Last-Modified` headers.
|
|
* **Invalidation:** Implement a strategy for invalidating cached content when the underlying data changes. This may involve purging the CDN cache or updating the `Cache-Control` headers.
|
|
* **Dynamic Content:** For dynamic content that cannot be cached, use the `Cache-Control: no-store` header. |