Rate limiting

Le rate limiting (limitation du débit de requêtes) restreint la fréquence à laquelle un client peut appeler une API, par exemple 100 requêtes par minute et par clé d’API. Les requêtes au-delà de la limite sont rejetées jusqu’à la réinitialisation de la fenêtre. Il protège le service contre la surcharge et les abus, empêche un client trop bavard d’affamer les autres et ralentit des attaques comme la devinette de mots de passe. La limite est généralement suivie par clé d’API, utilisateur, jeton ou adresse IP.

Exemple

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests et Retry-After font partie du standard HTTP. Les en-têtes qui indiquent le quota restant, comme X-RateLimit-Limit, X-RateLimit-Remaining et X-RateLimit-Reset, sont une convention répandue mais pas un standard unique : vérifiez ce que documente votre API.

Algorithmes courants

• Fenêtre fixe : compter les requêtes par minute calendaire. Simple, mais un client peut envoyer une double rafale à cheval sur la limite entre deux fenêtres.
• Fenêtre glissante : compter les requêtes sur les N dernières secondes, ce qui lisse cet effet de bord.
• Token bucket (seau à jetons) : les jetons se rechargent à un rythme constant et chaque requête en consomme un, ce qui autorise de courtes rafales jusqu’à la taille du seau tout en imposant un débit moyen.

Que tester

• La limite elle-même : envoyez limite + 1 requêtes et vérifiez que seule la requête en trop reçoit 429.
• Le rétablissement : après Retry-After ou l’heure de réinitialisation, les requêtes aboutissent à nouveau.
• La portée : le trafic d’un utilisateur ou d’une clé ne doit pas consommer le quota d’un autre. Vérifiez si les limites s’appliquent par clé, par utilisateur ou par IP, et si un client peut les contourner en changeant quelque chose de peu coûteux.
• Les endpoints sensibles : connexion, réinitialisation de mot de passe et vérification d’OTP doivent avoir des limites plus strictes que les lectures ordinaires.
• Le format de réponse : une requête rejetée renvoie 429 avec un corps utile, pas une 500 ni une connexion qui reste bloquée.
• Le comportement des clients : vos propres clients ralentissent et respectent Retry-After au lieu de réessayer en boucle serrée.

Le rate limiting et votre suite de tests

Les tests d’API parallèles et les tests de charge peuvent déclencher des limites proches de celles de la production et échouer pour des raisons sans rapport avec la modification testée. Utilisez des clés dédiées ou des limites relevées dans les environnements de test et, lorsqu’un test de charge doit mesurer la capacité, assurez-vous de mesurer le service et non le rate limiter.