Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La limitation est une technique que les API cloud utilisent pour limiter le nombre de requêtes qui peuvent être effectuées dans une période spécifique. La limitation de requêtes garantit que l’API reste disponible et performante pour tous les utilisateurs. Il empêche également tout utilisateur unique de consommer trop de ressources.
Vous pouvez faire l’expérience d’une limitation de requêtes de plusieurs façons. L’une des méthodes courantes consiste à utiliser des codes d’état HTTP. Par exemple, lorsque vous dépassez le nombre autorisé de requêtes, l’API peut retourner un code de statut 429 Too Many Requests. Cette réponse indique que vous avez émis trop de demandes dans une période spécifique et que vous devez ralentir. Toutes les API n’utilisent pas 429 : GitHub peut également répondre avec 403, et Anthropic utilise 529 quand son API entière est surchargée.
En plus des codes d’état, certaines API fournissent plus d’informations dans les en-têtes de réponse ou le corps. Par exemple, ils peuvent utiliser l’en-tête Retry-After pour indiquer la durée pendant laquelle vous devez attendre avant d’effectuer une autre requête.
Vous devez connaître les limites de limitation des API que vous utilisez et savoir comment gérer la limitation dans vos applications, afin qu’elles restent réactives et fiables lorsque l’API est sous une charge importante.
Comment la limitation affecte votre application
Lorsqu’une API limite votre application et que l’application ne la gère pas, l’application se bloque, affiche une erreur générique, retente si rapidement qu’elle reste soumise à une limitation de débit ou supprime silencieusement les 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 la limitation du débit
| Approach | Ce que vous trouvez | Ce qui vous manque |
|---|---|---|
| Attendez la fin de la production | Bridage réel | Tout, jusqu’à ce qu’un utilisateur appuie 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, les en-têtes Retry-After et les corps d’erreur réels de l’API, ainsi que la stratégie de nouvelle tentative de votre SDK. Votre application a également besoin d’un commutateur réservé aux tests pour atteindre le mock. |
| Appelez l’API réelle jusqu’à ce qu’elle vous limite | Comportement réel | Vous ne pouvez pas déclencher de limitation à la demande et vous utilisez votre quota réel |
| Interceptez le trafic réel de votre application et simulez la limitation | URL réelles, votre SDK réel et votre stratégie de réessai, et si votre application attend aussi longtemps que l’indique Retry-After |
Votre code considéré isolément. Conservez vos tests unitaires pour cela. |
Essayez-le dans votre application
Dev Proxy retourne des réponses de limitation pour les API que vous choisissez, tandis que votre application continue d’appeler les URL réelles. Il vous indique également quand votre application appelle à nouveau l’API avant la fin du délai Retry-After.
Téléchargez la configuration prédéfinie pour l’API que votre application appelle, puis démarrez le proxy de développement avec celle-ci :
devproxy config get microsoft-graph-rate-limiting
devproxy --config-file "~dataFolder/configs/microsoft-graph-rate-limiting/.devproxy/devproxyrc.json"
| API | Preset |
|---|---|
Microsoft Graph (OneDrive et SharePoint : /drive, /shares, /sites) |
microsoft-graph-rate-limiting |
| GitHub | github-rate-limiting |
| OpenAI | openai-throttling |
| Anthropic | anthropic-throttling |
Pour toute autre API, consultez Vérifier que mon application gère correctement la limitation. Pour installer Dev Proxy, consultez Configurer Dev Proxy.