API Platform supports HTTP caching FOLLOWING standard web conventions – RELEVANT for GET-heavy resources like Tag (chapter 12), which change RARELY.

Configuring cache headers per resource

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

max_age applies to PRIVATE caches (browsers), shared_max_age to PUBLIC caches (reverse proxy/CDN) – EXACTLY the two directives from the STANDARD HTTP Cache-Control header.

Checking the headers

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

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

Cache invalidation

API Platform OPTIONALLY integrates with Varnish or Symfony HttpCache and AUTOMATICALLY sends invalidation requests (via PURGE/BAN requests) as soon as a resource CHANGES – for OUR local setup WITHOUT its own reverse proxy, this STAYS a CONCEPTUAL overview, not a practical configuration.

When caching pays off

• Resources with RARE changes and FREQUENT reads (e.g. Tag).
• PUBLICLY accessible data, where a SHARED cache (CDN) noticeably RELIEVES the origin server.
• NOT useful for heavily PERSONALIZED or FREQUENTLY changing data like the user's own /api/projects list (chapter 55).