Le rate limiting limite le nombre d’appels reçus par une API pendant une période. Il protège une dépendance et répartit la capacité, mais un seuil mal choisi peut gêner un client légitime ou masquer une panne.
Définir la capacité
Mesurez les appels par route, client et période. Distinguez lecture, écriture et opérations coûteuses. Une limite globale peut laisser une recherche légère consommer la capacité prévue pour une création de commande.
Documentez la capacité de l’API et de ses dépendances. Une base ou un fournisseur externe peut avoir une limite plus basse que le serveur web. Les retries doivent respecter la réponse de limitation et utiliser un délai progressif.
Choisir la clé
Selon le service, la limite peut s’appliquer à une identité, un compte, une clé API ou une adresse réseau. Une adresse partagée par une entreprise ou un opérateur mobile ne doit pas être le seul critère pour un usage authentifié.
Pour une API publique, combinez plusieurs signaux et surveillez les abus. Les clés doivent avoir un propriétaire, une date de rotation et des permissions limitées. Les secrets ne doivent pas apparaître dans les journaux.
Communiquer le refus
Une réponse de limitation doit indiquer le statut approprié et, lorsque possible, le délai avant nouvelle tentative. Le client doit pouvoir distinguer un dépassement temporaire d’une erreur d’authentification ou d’une panne. Documentez les limites pour les intégrateurs.
Une file peut convenir à une opération longue. Le client reçoit alors un identifiant et consulte un statut, au lieu de répéter une requête qui déclenche plusieurs traitements. Notre article sur les workers et files d’attente décrit ce modèle.
Tester les scénarios
Simulez une hausse légitime, plusieurs clients concurrents et une clé compromise. Vérifiez les compteurs après un redémarrage et entre plusieurs instances. Un limiteur local peut produire des résultats différents d’un limiteur partagé.
Mesurez erreurs, latence et charge de la dépendance. Une règle efficace doit réduire la saturation sans augmenter fortement les refus des utilisateurs normaux. Ajustez le seuil à partir de ces données.
Gérer les exceptions
Un partenaire connu peut avoir un quota contractuel différent. Documentez l’exception et suivez son usage. Évitez les contournements permanents par adresse IP ou valeur cachée dans le code.
Sources : IETF, RFC 6585, OWASP, API Security.