Verwendung von HTTP-Cache-Header

1. Cache-Kontrolle

Der Cache-Control-Header ist der wichtigste HTTP-Caching-Header, der Direktiven für Caching-Mechanismen sowohl in Anfragen als auch in Antworten enthält. In REST-APIs wird er normalerweise in Antworten verwendet, um anzugeben, wie und wie lange eine Antwort zwischengespeichert werden kann.

    Direktiven für REST-API-Antworten:
        public or private: Gibt an, ob die Antwort von jedem Cache (public) oder nur vom Browser des Clients (private) zwischengespeichert werden kann.
        max-age=<seconds>: Gibt die maximale Zeit (in Sekunden) an, die die Antwort zwischengespeichert werden kann.
        no-cache: Weist Caches an, die Anfrage zur Überprüfung an den Ursprungsserver zu senden, bevor sie eine gecachte Kopie freigeben.
        no-store: Weist Caches an, die Antwort unter keinen Umständen zu speichern, was bei sensiblen Informationen sinnvoll ist.

Cache-Control: public, max-age=3600

Dies teilt allen Caches (und dem Browser des Clients) mit, dass die Antwort bis zu 3600 Sekunden (1 Stunde) ohne erneute Überprüfung gespeichert und wiederverwendet werden kann.

2. Gültigkeitsdauer

Vor der Cache-Kontrolle wurde der Expires-Header verwendet, um das genaue Datum oder die genaue Zeit festzulegen, nach der die Antwort als veraltet betrachtet wird. Er ist weniger flexibel als Cache-Control und wird von Cache-Control überschrieben, wenn beide vorhanden sind.


Expires: Wed, 21 Oct 2025 07:28:00 GMT

Dieser Header gibt an, dass die Antwort bis zum angegebenen Datum und zur angegebenen Uhrzeit zwischengespeichert werden kann.

3. ETag

Der ETag (Entity Tag) Header bietet eine eindeutige Kennung für eine bestimmte Version einer Ressource. Er ermöglicht eine genauere Kontrolle der Zwischenspeicherung und erlaubt es Clients, bedingte Anfragen zu stellen, um zu überprüfen, ob die zwischengespeicherte Kopie noch aktuell ist.

    Wenn der Server eine Antwort sendet, enthält diese einen ETag-Header.
    Der Client kann dann diesen ETag-Wert in den If-None-Match-Header nachfolgender Anfragen aufnehmen.
    Wenn sich die Ressource nicht geändert hat, gibt der Server einen 304 Not Modified-Statuscode zurück, der anzeigt, dass der Client die zwischengespeicherte Version verwenden kann.

ETag: "34a64df551425fcc55e4d42a148795d9f25f89d4"

4. zuletzt geändert

Ähnlich wie der ETag gibt der Last-Modified-Header das Datum und die Uhrzeit an, zu der die Ressource nach Ansicht des Servers zuletzt geändert wurde. Clients können dies nutzen, um mit Hilfe des If-Modified-Since-Headers bedingte Anfragen zu stellen. Wenn die Ressource seit dem angegebenen Zeitstempel nicht geändert wurde, antwortet der Server mit 304 Not Modified.

Last-Modified: Sat, 29 Oct 1994 19:43:31 GMT

Verwendung in REST-APIs

Beim Entwurf von REST-APIs ist die Entscheidung über die geeignete Caching-Strategie und die Header für jeden Endpunkt von entscheidender Bedeutung. Berücksichtigen Sie dabei die Art der Daten, die Häufigkeit ihrer Änderung und die Auswirkungen veralteter Daten. Für sehr dynamische Daten können Cache-Control: no-cache oder kurze max-age-Werte verwendet werden, während für statischere Ressourcen längere max-age-Werte oder ETag für bedingte Anfragen geeignet sein können.

Die Implementierung von HTTP-Caching-Headern kann die Effizienz und Reaktionsfähigkeit von REST-APIs erheblich verbessern, was zu einer besseren Erfahrung für Endbenutzer und einer geringeren Belastung der Server führt.