Comment gérer la limitation du débit

La limitation du débit est une technique courante utilisée par les fournisseurs d’API pour gérer le nombre de demandes qui peuvent être adressées à leur service pendant une période spécifique. Les fournisseurs d’API utilisent la limitation du débit pour s’assurer que leur service reste disponible et réactif à tous les utilisateurs, et pour éviter les abus ou surutilisation du service.

Lorsque vous utilisez des API cloud dans votre application, vous devez comprendre leurs limites de débit. Les techniques suivantes peuvent vous aider à gérer la limitation du débit dans vos applications :

  • Comprendre les limites de débit. Consultez la documentation de l’API que vous utilisez pour comprendre ses limites de débit. Les limites de débit peuvent dépendre du fournisseur d’API ou du plan de service que vous utilisez. Par exemple, certaines API peuvent avoir des limites de taux différentes pour les plans gratuits et payants.
  • Utilisez les informations de limitation de débit. Les API qui utilisent des limites de débit communiquent généralement les limites actuelles dans les en-têtes de réponse. Par exemple, l’en-tête RateLimit-Remaining indique le nombre de requêtes qui restent dans la fenêtre active. Si vous recevez une réponse avec cet en-tête défini sur 0, vous savez que vous avez atteint la limite de débit et devez attendre la fenêtre suivante avant d’envoyer une autre requête. L’en-tête RateLimit-Reset indique l’heure à laquelle la limite de débit est réinitialisée. Les noms et formats d’en-tête diffèrent par API : GitHub, par exemple, utilise x-ratelimit-remaining et x-ratelimit-reset en secondes d’époque UTC. Certaines API envoient les en-têtes uniquement après avoir atteint un seuil. C’est le cas, par exemple, lorsqu’il vous reste 10 % des demandes.
  • Optimiser l’utilisation de l’API. Certains services attribuent différents coûts à différentes demandes en fonction de leur complexité. Par exemple, certaines API peuvent facturer davantage pour les demandes qui retournent plus de données. Pour réduire le coût de votre application, optimisez l’utilisation de votre API en récupérant uniquement les données dont vous avez besoin. Utilisez des requêtes par lots si l’API les prend en charge. Ils vous aident à réduire le nombre de ressources nécessaires pour traiter la réponse et à respecter les limites de débit.
  • Implémentez un limiteur de débit local. Implémentez un limiteur de débit dans l’application lui-même pour limiter le nombre de requêtes pouvant être adressées à l’API dans une période spécifique. Vous pouvez le faire en utilisant des techniques telles que les algorithmes de seau à jetons ou de seau percé, qui permettent à l’application d’effectuer de nombreuses requêtes par période de temps. Toute demande supplémentaire est mise en file d'attente ou ignorée.
  • Évitez de dépasser les limites de débit. Lorsque vous dépassez les limites de débit, l’API limite vos requêtes, généralement avec un code d’état HTTP 429 Too Many Requests . Le throttling affecte le débit de votre application plus que ne le fait la limitation de débit. Utilisez les informations dans les en-têtes de réponse relatifs aux limites de débit pour rester dans les limites et éviter le bridage.

En utilisant ces techniques, vous pouvez créer des applications résilientes à la limitation du débit et continuer à fonctionner même lorsque l’API est sous une charge importante. Vérifiez ensuite que c’est bien le cas, car vous atteignez rarement une limite de débit pendant que vous développez.

Guide pratique pour tester la gestion de la limite de débit

Approach Ce que vous trouvez Ce que vous ne pouvez pas vérifier
Attendre qu’un problème survienne en production Limites de débit réelles Tout, jusqu’à ce qu’un utilisateur y soit confronté
Simuler l’API dans vos tests ou laisser votre agent de codage écrire la simulation Si votre code lit les en-têtes que vous avez simulés Les noms d’en-tête réels, les formats et le comportement de réinitialisation de l’API, ainsi que la stratégie de nouvelle tentative de votre Kit de développement logiciel (SDK). Votre application a également besoin d’un commutateur réservé aux tests pour accéder au simulateur.
Appeler l’API réelle jusqu’à atteindre la limite Comportement réel Vous ne pouvez pas atteindre la limite à la demande, vous épuisez votre quota réel et certaines limites ne sont réinitialisées qu’au bout d’une heure.
Interceptez le trafic réel de votre application et simulez la limite. De vraies URL, une limite et une fenêtre temporelle que vous choisissez, ainsi que les propres en-têtes de l’API Votre code isolé. Conservez vos tests unitaires pour cela.

Essayez-le dans votre application

Dev Proxy compte les demandes de votre application aux API que vous choisissez, ajoute des en-têtes de limite de débit aux réponses et répond avec 429 lorsque votre application dépasse la limite, tandis que votre application continue d’appeler les URL réelles. Vous choisissez la limite et la fenêtre de temps, de sorte que vous pouvez l’atteindre en une minute au lieu d’une heure.

Pour GitHub, téléchargez le préréglage et démarrez Dev Proxy avec celui-ci :

devproxy config get github-rate-limiting
devproxy --config-file "~dataFolder/configs/github-rate-limiting/.devproxy/devproxyrc.json"

Pour les appels Microsoft Graph à OneDrive et SharePoint (/drive, /shares, /sites), utilisez le préréglage microsoft-graph-rate-limiting. Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étape suivante

Tester que mon application gère la limitation de débit correctement

  • Dernière mise à jour :