Maîtriser les limites de débit API

Une limite de débit plafonne le nombre de requêtes qu'un client peut envoyer dans une fenêtre de temps donnée et renvoie un code 429 une fois ce plafond dépassé. Cette limite vise à empêcher un client de consommer une capacité qui appartient à tous. La bonne approche est donc de ralentir, plutôt que de renvoyer immédiatement la même requête.

Pourtant, la plupart des premières intégrations retentent immédiatement, transformant un refus temporaire en un blocage prolongé. Le client atteint la limite, réessaie, prolonge la fenêtre de mesure et se retrouve ralenti bien plus longtemps que la rafale initiale ne l'aurait exigé, souvent pendant qu'un développeur conclut que l'API est peu fiable. Votre propre configuration de limites (seuils par niveau, allocations de rafales et points de terminaison avec des plafonds plus stricts) est volontairement exclue : elle doit figurer dans une documentation versionnée, et non dans une vidéo qui vieillit mal.

Ce modèle suit une requête à travers huit scènes : une sur la raison d'être des limites, une sur la fenêtre et son comptage, une sur le contenu d'une réponse 429, deux sur le backoff et la nécessité d'augmenter le délai, une sur le jitter et l'effet de meute, une sur la lecture des en-têtes de limite de débit, et une sur la conception pour que la limite soit rarement atteinte.