API Platform unterstützt HTTP-Caching NACH Standard-Webkonventionen – RELEVANT für GET-lastige Ressourcen wie Tag (Kapitel 12), die sich SELTEN ändern.

Cache-Header pro Resource konfigurieren

#[ApiResource(
    cacheHeaders: [
        'max_age' => 3600,
        'shared_max_age' => 3600,
        'vary' => ['Authorization'],
    ],
    // ...
)]

max_age gilt für PRIVATE Caches (Browser), shared_max_age für ÖFFENTLICHE Caches (Reverse-Proxy/CDN) – GENAU die zwei Direktiven aus dem STANDARD-HTTP-Cache-Control-Header.

Die Header prüfen

curl -k -i https://localhost/api/tags | grep -i cache

cache-control: max-age=3600, public, s-maxage=3600
vary: Authorization

Cache-Invalidierung

API Platform integriert sich OPTIONAL mit Varnish oder Symfony HttpCache und sendet AUTOMATISCH Invalidierungs-Anfragen (via PURGE/BAN-Requests), sobald sich eine Resource ÄNDERT – für UNSER lokales Setup OHNE eigenen Reverse-Proxy BLEIBT das ein KONZEPTIONELLER Überblick, keine praktische Konfiguration.

Wann sich Caching lohnt

• Ressourcen mit SELTENEN Änderungen und HÄUFIGEN Lesezugriffen (z. B. Tag).
• ÖFFENTLICH zugängliche Daten, bei denen ein SHARED Cache (CDN) den Ursprungsserver spürbar ENTLASTET.
• NICHT sinnvoll für stark PERSONALISIERTE oder HÄUFIG wechselnde Daten wie die eigene /api/projects-Liste (Kapitel 55).