Rate Limiting API

Protégez vos API et respectez les limites des APIs que vous consommez.

Le rate limiting est un mĂ©canisme de protection qui limite le nombre de requĂȘtes qu'un client peut effectuer dans un intervalle de temps donnĂ©. Du cĂŽtĂ© fournisseur, il protĂšge vos serveurs contre la surcharge. Du cĂŽtĂ© consommateur, il vous oblige Ă  gĂ©rer intelligemment vos appels aux APIs tierces.

Une mauvaise gestion du rate limiting peut casser vos intégrations : erreurs 429 en cascade, dégradation de l'expérience utilisateur, voire blocage temporaire de votre accÚs à une API critique.

Ce guide couvre les deux perspectives : implémenter le rate limiting pour protéger vos API, et le gérer intelligemment quand vous consommez des APIs tierces.

Concepts du Rate Limiting

Comprenez les mécanismes fondamentaux :

  • Limite (Limit) : nombre maximum de requĂȘtes autorisĂ©es dans une fenĂȘtre de temps (ex: 100 req/min, 1000 req/heure).
  • FenĂȘtre (Window) : pĂ©riode sur laquelle la limite s'applique. Peut ĂȘtre fixe (par minute calendaire) ou glissante (les 60 derniĂšres secondes).
  • Identifiant : ce qui identifie le client : IP, API key, user ID, tenant. DĂ©termine la granularitĂ© des limites.
  • Quota : limite sur une pĂ©riode plus longue (jour, mois), souvent liĂ©e au plan de tarification.

Algorithmes de Rate Limiting

Différentes approches avec leurs avantages :

  • Fixed Window : limite par intervalle fixe (ex: par minute calendaire). Simple mais permet des pics en chevauchant deux fenĂȘtres.
  • Sliding Window : fenĂȘtre glissante qui lisse les limites. Plus prĂ©cis mais nĂ©cessite de stocker plus d'Ă©tat.
  • Token Bucket : accumulation de "tokens" Ă  rythme constant. Permet des bursts tant que des tokens sont disponibles. Flexible et populaire.
  • Leaky Bucket : file d'attente avec traitement Ă  rythme fixe. Lisse parfaitement le trafic mais peut ajouter de la latence.

Surveiller le Rate Limiting

Métriques clés pour anticiper les problÚmes :

  • Utilisation du quota : quel pourcentage de votre limite utilisez-vous ? Alertez avant d'atteindre 80% pour avoir le temps de rĂ©agir.
  • Erreurs 429 : nombre de requĂȘtes rejetĂ©es. Doit rester proche de zĂ©ro pour les APIs que vous consommez.
  • Temps avant reset : via le header X-RateLimit-Reset. Permet de programmer intelligemment les retries.
  • RĂ©partition dans le temps : Ă©vitez les pics en rĂ©partissant vos appels. Un volume stable est plus facile Ă  gĂ©rer qu'un burst.

Headers de Rate Limiting

Les headers standards pour gérer les limites :

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 67
X-RateLimit-Reset: 1640995200
Retry-After: 42

# Sur erreur 429:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1640995260

Parsez ces headers dans vos clients pour adapter votre comportement : ralentir quand Remaining baisse, attendre Retry-After aprĂšs un 429.

Gérer les Limites CÎté Client

Stratégies pour respecter les limites des APIs :

  1. Lire les headers : surveillez X-RateLimit-Remaining à chaque réponse. Ralentissez proactivement quand il baisse.
  2. Exponential backoff : aprĂšs un 429, attendez de plus en plus longtemps entre chaque retry (1s, 2s, 4s...).
  3. File d'attente : implémentez une queue qui régule le débit d'envoi pour ne jamais dépasser la limite.
  4. Caching agressif : cachez les réponses pour éviter des appels redondants. Chaque appel économisé préserve le quota.

Bonnes Pratiques

Recommandations pour une gestion saine :

  • Documentez vos limites : rendez les limites visibles dans votre documentation et vos dashboards. L'Ă©quipe doit savoir oĂč on en est.
  • Alertes proactives : alertez Ă  70-80% d'utilisation, pas Ă  100%. Le temps de rĂ©agir avant le blocage est crucial.
  • Plan de contingence : que faire si vous atteignez la limite ? Fallback, cache, file d'attente, upgrade de plan ?
  • Testez en staging : simulez des conditions de rate limiting en staging pour valider le comportement de votre application.

Checklist Rate Limiting

  • Limites des APIs consommĂ©es documentĂ©es
  • Headers de rate limiting parsĂ©s dans les clients
  • Exponential backoff implĂ©mentĂ© sur les 429
  • Alertes sur utilisation du quota > 70%
  • Plan de contingence en cas de blocage

Questions Fréquentes

Rate limit par IP ou par API key ?

Par API key est plus précis et équitable. Par IP peut pénaliser des clients légitimes derriÚre un NAT. Idéalement, combinez les deux avec des limites différentes.

Comment choisir les limites ?

Analysez l'usage réel, identifiez les patterns normaux et les abus. Fixez les limites au-dessus de l'usage normal mais en dessous de ce que vos serveurs peuvent supporter.

Faut-il retourner 429 ou 503 ?

429 (Too Many Requests) est spécifique au rate limiting et inclut Retry-After. 503 indique une indisponibilité temporaire plus générale.

Comment gérer les bursts légitimes ?

Token bucket permet des bursts dans la limite du bucket. Alternativement, offrez des limites plus élevées aux clients premium ou sur demande.

Peut-on monitorer le rate limiting des APIs tierces ?

MoniTao peut alerter sur les erreurs 429. Pour un suivi plus fin du quota, parsez les headers dans votre code et exposez les métriques.

Comment tester le rate limiting ?

Envoyez des requĂȘtes en boucle jusqu'Ă  recevoir des 429. VĂ©rifiez que le backoff fonctionne et que l'application se rĂ©tablit aprĂšs le reset.

Conclusion

Le rate limiting protÚge les API contre les abus et garantit une qualité de service équitable. Que vous l'implémentiez ou que vous le subissiez, une gestion intelligente est essentielle.

MoniTao vous alerte sur les erreurs 429 et vous aide à détecter les problÚmes de quota avant qu'ils n'impactent vos utilisateurs. Combinez monitoring et bonne implémentation client pour des intégrations robustes.

Liens utiles

PrĂȘt Ă  dormir sur vos deux oreilles ?

Commencez gratuitement, sans carte bancaire.

Créer mon compte Voir les tarifs