Was ist API-Caching? Header, Schichten und Invalidierung

Was ist API-Caching?

API-Caching bedeutet, eine API-Antwort zu speichern, damit spätere identische Anfragen aus der gespeicherten Kopie beantwortet werden, statt die Arbeit erneut auszuführen. Die Kopie kann im Client, in einem CDN, in einem API-Gateway oder in Ihrer Anwendung liegen. Eine zwischengespeicherte Antwort ist schneller und entlastet das Backend, kann aber veraltet sein. Jede Caching-Entscheidung ist deshalb ein Abwägen zwischen Geschwindigkeit und Aktualität.

Wo Antworten zwischengespeichert werden

• Client- oder Browser-Cache. Ein privater Cache für einen einzelnen Nutzer. Er spart den Netzwerkweg vollständig.
• CDN oder Reverse Proxy. Ein gemeinsamer Cache nahe an den Nutzern. Siehe Content Delivery Networks. Er hilft nur bei Antworten, die für viele Nutzer gleich sind.
• API-Gateway. Ein gemeinsamer Cache vor Ihren Diensten, gesteuert durch die Regeln des Gateways.
• Anwendungs-Cache. Arbeitsspeicher im Prozess oder ein Speicher wie Redis. Oft cacht man die teure Abfrage oder den berechneten Wert statt der ganzen HTTP-Antwort.
• Datenbank-Cache. Puffer und Abfrage-Caches innerhalb der Datenbank, meist automatisch.

Die HTTP-Header, die es steuern

RFC 9111 legt fest, wie sich HTTP-Caches verhalten. Die wichtigsten Antwort-Header:

• Cache-Control: max-age=60: Die Antwort bleibt 60 Sekunden aktuell. s-maxage legt die Aktualität nur für gemeinsame Caches fest.
• Cache-Control: no-cache: Die Antwort darf gespeichert werden, muss aber vor jeder Wiederverwendung beim Ursprungsserver neu validiert werden. Es heißt nicht "nicht cachen".
• Cache-Control: no-store: Kein Cache, weder privat noch gemeinsam, soll die Antwort speichern.
• Cache-Control: private: Nur ein privater Cache wie der Browser darf speichern. public erlaubt gemeinsame Caches und wird nur gebraucht, wenn die Anfrage einen Authorization-Header trug.
• ETag und If-None-Match: Der Client sendet den gespeicherten Validator, und der Server antwortet bei Unverändertem mit 304 Not Modified ohne Body.
• Vary: Nennt die Request-Header, die die Antwort verändern, etwa Accept-Language, damit jede Variante getrennt gecacht wird.
• stale-while-revalidate und stale-if-error: Erweiterungen aus RFC 5861, mit denen ein Cache eine veraltete Kopie ausliefern darf, während er sie erneuert oder wenn der Ursprung ausfällt.

Fehlt jede Angabe zur Aktualität, dürfen Caches trotzdem heuristische Aktualität anwenden, üblicherweise einen Bruchteil der Zeit seit Last-Modified. Setzen Sie Cache-Control daher ausdrücklich. Der MDN-Leitfaden zum HTTP-Caching enthält Beispiele.

Beispiel

Ein öffentlicher Endpunkt, GET /api/v1/products, ändert sich einige Male pro Stunde. Er kann mit Cache-Control: public, max-age=60 und einem ETag antworten, sodass ein CDN die meisten Lesezugriffe abfängt und Clients günstig neu validieren. Ein personalisierter Endpunkt, GET /api/v1/me, sollte Cache-Control: private, no-cache mit einem ETag senden: Der Browser darf ihn behalten, muss aber zuerst beim Server nachfragen, und kein gemeinsamer Cache speichert ihn. Der Cache-Schlüssel enthält die vollständige URL, daher gehört bei einer paginierten Liste die Seite oder der Cursor in den Query-String; siehe API-Paginierung.

Strategien und Invalidierung

• Cache-aside. Die App prüft den Cache, lädt bei einem Fehlzugriff aus der Quelle und speichert das Ergebnis. Das einfachste und häufigste Muster.
• Write-through. Schreibzugriffe aktualisieren Cache und Quelle gemeinsam. Lesen bleibt konsistent, Schreiben wird langsamer.
• TTL-Ablauf. Einträge laufen ab. Einfach, aber Daten können nach einer Änderung bis zur TTL veraltet sein.
• Löschen bei Änderung. Betroffene Schlüssel oder Tags werden bei Datenänderung entfernt. Präzise, aber jeder Schreibende muss wissen, was zu löschen ist.
• Versionierte URLs. Eine Version oder ein Inhalts-Hash in der URL erzeugt bei jeder Änderung einen neuen Cache-Schlüssel.

Bei der Invalidierung entstehen die meisten Caching-Fehler. Unser Leitfaden zur Cache-Invalidierung in Performance-Tests zeigt, wie veraltete und kalte Caches Ergebnisse verfälschen.

Häufige Fehler

• Personalisierte Antworten in einen gemeinsamen Cache lassen. Markieren Sie sie als private. Ein Cookie allein macht eine Antwort nicht privat.
• Fehlendes oder zu breites Vary. Ohne es wird die falsche Variante ausgeliefert. Ein Vary auf User-Agent zersplittert den Cache so stark, dass er kaum noch trifft.
• Fehler cachen. Ein 500, der mit langer Aktualität gespeichert wird, schlägt für alle weiter fehl. Geben Sie Fehlerantworten kurze oder keine Aktualität.
• Cache Stampede. Läuft ein stark genutzter Schlüssel ab, treffen viele Anfragen gleichzeitig ins Leere und belasten den Ursprung. Nutzen Sie eine Sperre beim Neuaufbau, vorzeitiges Erneuern oder stale-while-revalidate.
• Annehmen, dass ein POST gecacht wird. RFC 9111 erlaubt das Cachen anderer Methoden als GET nur, wenn die Methode es zulässt und festlegt, wie der Cache-Schlüssel gebildet wird; in der Praxis speichern Caches POST-Antworten selten. Idempotenz betrifft sichere Wiederholungen, nicht die Cache-Fähigkeit.
• Nicht messen. Ohne Trefferquote und Ursprungslast pro Endpunkt lässt sich keine TTL abstimmen.

Einen Cache testen und überwachen

Testen Sie Caching auf zwei Arten. Funktional: Senden Sie dieselbe Anfrage zweimal und prüfen Sie Header und Laufzeit. Eine gecachte Antwort sollte schneller sein und die beabsichtigten Aktualitäts-Header tragen. Unter Last: Fahren Sie den Endpunkt mit warmem Cache und mit Cache-Busting-Parametern und vergleichen Sie Antwortzeiten und die Last, die Ihren Ursprung erreicht, in Ihren eigenen Metriken. Als Einstieg eignet sich ein kostenloser API-Lasttest. Nach dem Release übernimmt API-Monitoring: LoadFocus API Monitoring kann Statuscode, Body, Header und Antwortzeit prüfen, sodass ein Deploy, der Cache-Control verliert oder einen gecachten Endpunkt langsam macht, auffällt. Kostenlose Checks laufen alle 5 Minuten. Auch Rate Limits hängen mit Caching zusammen, denn Treffer aus dem Cache erreichen den Limiter meist gar nicht; siehe häufige Ursachen für API-Rate-Limiting.

Häufige Fragen: API-Caching

Was sollte ich zuerst cachen?

Beginnen Sie mit lesenden Endpunkten, die langsam sind, oft abgefragt werden, sich selten ändern und für viele Nutzer dieselbe Antwort liefern. Latenz und Anfragevolumen pro Endpunkt zeigen, wo es sich lohnt.

Was ist der Unterschied zwischen no-cache und no-store?

no-cache erlaubt einem Cache, die Antwort zu speichern, erzwingt aber vor jeder Wiederverwendung eine Validierung beim Ursprung. no-store weist Caches an, die Antwort gar nicht zu speichern.

Kann ich POST-Anfragen cachen?

Selten. HTTP-Caches speichern vor allem Antworten auf GET. Manche APIs cachen suchartige POSTs in der Anwendungsschicht mit explizitem Schlüssel, aber ein CDN oder Browser übernimmt das nicht von selbst.

Ist ein CDN dasselbe wie API-Caching?

Nein. Ein CDN ist ein Ort, an dem Caching stattfindet, nämlich am Edge. API-Caching umfasst alle Schichten vom Browser bis zur Datenbank.

Wie cache ich eine GraphQL-API?

Abfragen reisen meist im POST-Body, daher greift URL-basiertes Caching nicht. Gängige Optionen sind Persisted Queries als GET oder Caching auf Resolver- oder Anwendungsebene.

Woran erkenne ich, dass eine Antwort aus dem Cache kam?

Vergleichen Sie die Laufzeit, prüfen Sie den Age-Header und einen eventuellen Cache-Status-Header Ihres CDN und beobachten Sie, ob die Anfrage in Ihren Ursprungs-Logs ankommt.