Qu'est-ce que le Caching d'API ?

Qu'est-ce que le caching d'API ?

Le caching d'API est la pratique de stocker les réponses d'une API pour que les requêtes identiques suivantes puissent être servies depuis le cache au lieu de réexécuter le travail sous-jacent. La réponse en cache est généralement assez fraîche — pour beaucoup d'endpoints, les données changent bien moins souvent qu'elles ne sont lues — et servir depuis le cache est dramatiquement plus rapide que recalculer depuis les bases de données ou services en aval. Le caching est l'une des optimisations à plus fort levier en ingénierie d'API : un cache bien placé peut couper la latence p95 de 10-100x et réduire la charge backend de 90%+.

Les emplacements de cache s'empilent : navigateur → CDN → API gateway → mémoire d'application → cache distribué (Redis/Memcached) → cache de requêtes de base de données. Chaque couche coupe une fraction des requêtes, avec des taux de hit progressivement plus élevés et un coût plus bas à mesure que vous vous rapprochez de l'utilisateur. Une stratégie efficace de caching d'API choisit la bonne couche (ou les couches) pour chaque endpoint en fonction des patterns d'accès et des exigences de fraîcheur.

Les cinq principales couches de caching d'API

1. Cache client / navigateur

Le navigateur stocke les réponses basées sur les headers HTTP cache-control. Zéro aller-retour quand caché. Mieux pour le contenu sûr à cacher localement par utilisateur (assets statiques, données de référence publiques). Contrôlé par Cache-Control: max-age=3600 et ETags.

2. Cache edge CDN (Cloudflare, CloudFront, Fastly)

Caché aux POPs edge près des utilisateurs. Temps de réponse ~10-50ms globalement. Mieux pour le contenu caché pour de nombreux utilisateurs (APIs publiques, données anonymisées, endpoints marketing). Contrôlé par les headers Cache-Control + règles de cache spécifiques au CDN.

3. Cache d'API gateway (AWS API Gateway, Kong, Apigee)

Cache centralisé devant vos APIs. Réduit les hits backend sans coopération navigateur/CDN. Utile pour la logique partagée avant le routing vers les services.

4. Cache au niveau application (in-process ou distribué)

Le plus flexible : cachez n'importe quoi en mémoire (in-process) ou dans Redis/Memcached (partagé entre instances). Mieux pour les réponses calculées qui ne valent pas la peine d'être poussées vers le CDN. Pattern courant : cachez la requête de lecture coûteuse, pas la réponse HTTP complète.

5. Cache de requêtes de base de données

Beaucoup de bases de données cachent les plans de requête et les résultats fréquents en interne. Moins de contrôle mais souvent automatique. shared_buffers de PostgreSQL, query cache de MySQL (déprécié post-8.0), Redis comme couche de cache de base de données.

Headers de caching HTTP (le standard)

RFC 9111 définit la sémantique de cache que chaque CDN, navigateur et reverse proxy suit :

• Cache-Control: public, max-age=3600 — cachable par n'importe qui pendant 1 heure.
• Cache-Control: private, max-age=300 — seul le navigateur de l'utilisateur peut cacher (pas le CDN), 5 minutes.
• Cache-Control: no-store — ne jamais cacher (données sensibles).
• Cache-Control: no-cache — doit revalider avant réutilisation (caché mais conditionnel).
• Cache-Control: stale-while-revalidate=60 — servez stale jusqu'à 60s en plus pendant que vous récupérez fresh en arrière-plan. Grande victoire UX.
• ETag: "abc123" — empreinte du contenu. Le client envoie If-None-Match: "abc123" ; le serveur répond 304 si inchangé.
• Vary: Accept-Encoding, Authorization — la clé de cache inclut ces headers (contenu différent par encoding/utilisateur).

Stratégies de caching courantes

• Cache-aside (lazy loading). L'app vérifie le cache ; en cas de miss, récupère depuis la source et remplit le cache. Simple, courant.
• Read-through. La couche de cache récupère transparemment en cas de miss. Moins de code app ; nécessite que le cache connaisse la source.
• Write-through. Les écritures vont au cache + source simultanément. Le cache est toujours cohérent mais écritures plus lentes.
• Write-back. Les écritures vont au cache ; la source est mise à jour async. Écritures rapides mais risque de perte en cas d'échec de cache.
• Refresh-ahead. Le cache rafraîchit proactivement avant l'expiration du TTL. Latence lisse, nécessite une bonne prédiction.

Invalidation de cache : le problème difficile

La citation de Phil Karlton est célèbre : "Il n'y a que deux choses difficiles en informatique : l'invalidation de cache et nommer les choses." Stratégies :

• Basée sur TTL. Définissez Cache-Control max-age. Simple. Compromis : données obsolètes jusqu'au TTL après le changement.
• Purge manuelle. Appelez l'API CDN/cache pour invalider des clés spécifiques quand les données changent. Précis ; nécessite que les écritures sachent quelles clés.
• URLs versionnées. Ajoutez la version (/api/products?v=42) pour que les changements obtiennent des URLs fraîches. Les anciennes entrées de cache meurent naturellement.
• Invalidation pilotée par événements. Pub/sub diffuse "produit 42 a changé" ; les couches de cache écoutent et purgent. Le plus précis ; le plus complexe.
• Surrogate keys (Cache tags). Taguez les réponses avec des clés logiques ("user:42", "products") et purgez par tag. Fastly, Cloudflare Enterprise le supportent.

Erreurs courantes de caching d'API

• Cacher des réponses authentifiées publiquement. Les données d'un utilisateur connecté finissent dans un cache partagé ; un autre utilisateur les voit. Définissez toujours Cache-Control: private pour les réponses personnalisées.
• Oublier les headers Vary. Le cache renvoie une réponse gzippée à un client demandant l'encoding identity. Incluez toujours Vary: Accept-Encoding.
• TTL trop long. Heures de données obsolètes après chaque mise à jour. Ajustez le TTL à votre fréquence de changement réelle.
• TTL trop court. Taux de hit de cache <50% signifie que vous ne cachez pas vraiment. Visez 90%+ taux de hit sur les endpoints cachés.
• Cache stampede. Quand le TTL expire, 1 000 requêtes concurrentes ratent toutes et frappent la base de données. Atténuez avec des locks ("un seul fetch en cas de miss"), refresh-ahead, ou stale-while-revalidate.
• Cacher des erreurs. Une erreur 500 est cachée pendant 5 minutes ; les utilisateurs continuent de voir la réponse cassée. Définissez toujours Cache-Control: no-store sur les réponses d'erreur.
• Pas d'observabilité. Sans métriques sur le taux de hit, taux de miss et charge d'origine, vous ne pouvez pas ajuster. Tracez celles-ci par endpoint.

FAQ : Caching d'API

Comment savoir quoi cacher ?

Profilez votre API : quels endpoints sont les plus lents ? Les plus demandés ? Ont des données stables ? Ce sont des candidats au caching. Des outils comme Datadog APM montrent la latence d'endpoint et le taux de requête côte à côte.

Quel est un bon taux de hit de cache ?

Pour les endpoints bien cachés, visez 90%+ de taux de hit au CDN. Plus bas signifie que les TTLs sont trop courts ou que vous cachez des choses qui ne devraient pas l'être (données par utilisateur). En dessous de 50% signifie que le caching aide à peine.

Puis-je cacher des requêtes POST ?

Généralement non — la sémantique HTTP traite les POSTs comme changeant l'état. Certaines APIs cachent les POSTs idempotents (par ex., recherche) à la couche application avec des clés de cache explicites, mais le CDN ne fera pas cela pour vous.

Comment le caching d'API interagit-il avec la limitation de taux ?

Les hits de cache contournent typiquement les limites de taux (ils n'atteignent pas l'endpoint à taux limité). Cela protège les backends mais signifie que les utilisateurs abusifs peuvent marteler un endpoint caché librement. Pour les endpoints sensibles, limitez le taux à l'edge du CDN.

Et le caching GraphQL ?

Plus délicat que REST. La requête est dans le corps POST, donc le caching basé sur l'URL échoue. Solutions : requêtes persistantes (transformez les requêtes complexes en IDs, cachables comme GET), automatic persisted queries d'Apollo, hints de cache au niveau requête.

Comment tester le caching d'API ?

Fonctionnellement : envoyez des requêtes identiques, vérifiez que la seconde est plus rapide (header X-Cache: HIT, latence plus basse). Sous charge : test de charge avec cache activé vs. désactivé pour mesurer la protection du backend.

Quelle est la différence entre caching et CDN ?

Un CDN est un réseau de livraison avec des caches aux POPs edge. "Caching" est la pratique plus large de stocker des réponses à n'importe quelle couche. Le caching CDN est un cas spécifique.

Comment LoadFocus se rapporte à la stratégie de caching d'API

La valeur du caching d'API ne se montre que sous trafic concurrent réaliste. Les tests de charge d'API LoadFocus mesurent le taux de hit du backend (cache miss = trafic frappant votre origine) sous concurrence réaliste, faisant ressortir les cache stampedes et les TTLs inefficaces. Le monitoring d'API trace le taux de hit du cache au fil du temps pour que vous attrapiez les régressions quand un déploiement contourne accidentellement le cache.