Qu’est-ce que la limitation du débit ?

La limitation du débit est un mécanisme de contrôle que les API cloud utilisent pour réglementer le nombre de demandes qu’un utilisateur peut effectuer dans un temps spécifique. Les producteurs d’API cloud utilisent la limitation du débit pour s’assurer que le flux de requêtes ne surcharge pas le service. La limitation de débit définit une limite sur la vitesse et le volume des appels d’API. Les limites de débit sont généralement définies en termes de demandes par période de temps.

Pourquoi les API cloud utilisent la limitation du débit

  • Empêcher la surcharge. La limitation du débit garantit que le serveur d’API reste stable et réactif en empêchant tout utilisateur ou service unique de l’inonder avec trop de requêtes.
  • Assurez-vous que l’utilisation est équitable. La limitation du débit applique des stratégies d’utilisation équitable en s’assurant qu’aucun utilisateur unique ne monopolise les ressources de l’API. La limitation du débit permet un accès équitable à tous les utilisateurs.
  • Augmentez la sécurité. La limitation du débit permet d’atténuer les attaques par déni de service distribué et d’autres comportements abusifs en limitant le nombre de requêtes provenant de sources potentiellement malveillantes.
  • Gérer les coûts. Pour les fournisseurs de services cloud, la limitation des débits aide à gérer les coûts opérationnels en empêchant l’utilisation imprévisible ou excessive des ressources.
  • Maintenir la qualité de service. La limitation du débit garantit une qualité de service cohérente pour tous les utilisateurs en empêchant les pics de trafic.

Comment vous rencontrez une limitation de débit dans vos applications

Lorsque vous créez des applications qui intègrent des API cloud, consultez leur documentation pour vérifier s’ils prennent en charge la limitation du débit. Si c'est le cas, vous recevez des en-têtes de réponse RateLimit-... ou X-RateLimit-... avec des informations sur les limites de débit. Vous pouvez utiliser ces informations dans votre application pour vous assurer que vous ne dépassez pas les limites de débit de l’API. Par exemple, l’en-tête RateLimit-Remaining indique le nombre de requêtes restantes 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. Certaines API envoient les RateLimit-... en-têtes uniquement après avoir atteint un seuil. Par exemple, lorsque vous avez 10 % des requêtes restantes.

Lorsque vous dépassez la limite de débit, l’API limite vos requêtes et retourne un code d’état HTTP 429 Too Many Requests . Certaines API peuvent également envoyer un Retry-After en-tête pour indiquer la durée pendant laquelle vous devez attendre avant d’envoyer une autre requête. Certaines API ne suivent pas ce modèle. GitHub, par exemple, peut répondre avec 403 au lieu de 429.

Pour éviter la limitation et vous assurer que votre application reste réactive, implémentez la limitation du débit dans votre application. Selon votre pile technologique, différentes bibliothèques peuvent vous aider à gérer la limitation du débit dans votre application. Après avoir implémenté la limitation de débit dans votre application, testez pour voir s’il gère correctement la limitation du débit.

Comment la limitation de débit affecte-t-elle votre application ?

Lorsqu’une API commence à retourner 429 des réponses, une application qui ne les gère pas se bloque, affiche une erreur générique, réessaie si vite qu’elle reste limitée, ou supprime silencieusement des données. Vous voyez rarement tout cela pendant que vous développez, car l’API est rapide, vous êtes le seul utilisateur et vos données de test sont petites.

Comment tester que votre application gère les limites de débit

Approach Ce que vous trouvez Ce qui vous manque
Attendre la mise en production Limites de débit réelles Tout, jusqu’à ce qu’un utilisateur clique dessus
Simuler l’API dans vos tests ou laisser votre agent de codage écrire la simulation Si votre branche de nouvelle tentative s’exécute Les codes d’état réels de l’API, les en-têtes de limite de débit et les corps d’erreurs, ainsi que la stratégie de nouvelle tentative de votre SDK. Votre application a également besoin d’une option uniquement pour les tests afin d’accéder à l’environnement simulé.
Appelez l’API réelle jusqu’à ce qu’elle vous limite Comportement réel Vous ne pouvez pas atteindre la limite avec l’utilisation à la demande seule, vous utilisez votre quota réel et certaines limites ne sont réinitialisées qu’après une heure
Interceptez le trafic réel de votre application et simulez la limitation De vraies URL, votre véritable SDK et votre politique de réessai, ainsi que les propres en-têtes de l’API, avec une limite que vous choisissez 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 retourne 429 lorsque votre application dépasse la limite, tandis que votre application continue d’appeler les URL réelles. Il vous indique également quand votre application appelle à nouveau l’API avant la réinitialisation de la limite.

Téléchargez le préréglage pour l’API appelée par votre application, puis démarrez le proxy de développement 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 définir votre propre limite pour n’importe quelle API, consultez Simuler les réponses de l’API de limitation du débit. Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étapes suivantes

Comment gérer la limitation du débit

  • Dernière mise à jour :