429 Trop de demandes : ce que cela signifie et comment le gérer

L’API retourne 429 Too Many Requests lorsque votre application a envoyé plus de demandes que l’API l’autorise pendant une période donnée. La demande elle-même est correcte. Vous l’avez envoyé trop souvent, donc l’API l’a rejetée. Si vous attendez et l’envoyez à nouveau, cela fonctionne généralement. La réponse inclut souvent un Retry-After en-tête qui vous indique le temps d’attente. Pour plus d’informations, consultez RFC 6585, section 4.

Chaque API implémente des limites de débit différemment. Le code d’état, les en-têtes et le corps de l’erreur varient, de sorte que le code qui gère correctement une API peut mal gérer la suite.

API Status Comment savoir combien de temps attendre Attention à
GitHub 403 ou 429 retry-after s’il est présent, sinon x-ratelimit-reset (secondes depuis l’époque Unix (UTC)) lorsque x-ratelimit-remaining est 0, sinon au moins 1 minute Un 403 peut être une limite de débit ou une autorisation manquante. Lisez les en-têtes pour les séparer.
OpenAI 429 retry-after Quelque 429, comme credit_balance_exhausted, signifient que les nouvelles tentatives n’aideront pas. Vérifiez error.code.
Anthropic 429 retry-after Une limite de dépense 429 n’a pas retry-after et continue à échouer jusqu’à ce que l’accès reprend. Une API surchargée retourne 529, et non 429.
Microsoft Graph 429 Retry-After (secondes) Les limites diffèrent par service, par exemple SharePoint et Outlook.

Comment gérer un 429

  1. Déterminez s’il faut réessayer ou non. Si l’erreur indique que votre quota, vos crédits ou votre limite de dépense sont utilisés, les nouvelles tentatives ne vous aideront pas. Indiquez à l’utilisateur et créez une alerte pour vous-même.
  2. Attendez tant que l’API vous demande. Si la réponse a Retry-After, attendez ce temps. Il s’agit d’un nombre de secondes ou d’une date HTTP. Si l'API utilise des en-têtes de limite de débit à la place, comme ceux de GitHub x-ratelimit-reset, attendez jusqu'à l'heure de réinitialisation.
  3. Sinon, reculez. Sans indication de l’API, réessayez avec un backoff exponentiel et une gigue aléatoire, puis arrêtez après quelques tentatives.
  4. Indiquez à l’utilisateur ce qui se passe. « Occupé, réessayer en 5 secondes » vaut mieux qu’un spinner interminable.
  5. Ralentissez avant la prochaine erreur 429. Si l’API envoie des en-têtes de limite de débit, utilisez le nombre restant pour adapter le rythme de vos requêtes.
async function fetchWithRetry(url, options, attempts = 3) {
  for (let attempt = 1; ; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === attempts) {
      return response;
    }
    const retryAfter = response.headers.get('retry-after');
    const waitMs = retryAfter
      ? (isNaN(retryAfter) ? new Date(retryAfter) - Date.now() : retryAfter * 1000)
      : 2 ** attempt * 1000 + Math.random() * 1000;
    await new Promise(resolve => setTimeout(resolve, Math.max(waitMs, 0)));
  }
}

De nombreux SDK réessaient les erreurs 429 pour vous. Par exemple, le Kit de développement logiciel (SDK) OpenAI Python retente 2 fois par défaut, et le gestionnaire de résilience standard .NET retente 3 fois et respecte Retry-After. Lorsque le kit de développement logiciel (SDK) a épuisé toutes ses tentatives, votre code reçoit l’erreur, il faut donc toujours prévoir une solution de repli.

Comment tester que votre application gère 429

Vous voyez rarement un 429 pendant que vous développez. L’API est rapide, vous êtes le seul utilisateur et vos données de test sont petites. Ainsi, la façon dont vous testez la gestion 429 détermine si vous trouvez les bogues avant que vos utilisateurs ne le fassent.

Approach Ce que vous trouvez Ce qui vous manque
Attendre la mise en production Échecs réels Tout, jusqu’à ce qu’un utilisateur le frappe
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, les en-têtes et les corps d’erreurs de l’API et la stratégie de nouvelle tentative de votre SDK. Votre application a également besoin d’un commutateur uniquement pour les tests afin d’accéder au mock.
Appelez l’API réelle jusqu’à ce qu’elle vous limite Comportement réel Vous ne pouvez pas déclencher de 429 à la demande, et vous épuisez votre quota réel
Interceptez le trafic réel de votre application et retournez des 429 à la demande De vraies URL, votre véritable SDK et politique de nouvelle tentative, et le format 429 propre à l’API Rien dans votre application ne change, de sorte qu’elle ne teste pas votre code de manière isolée. Conservez vos tests unitaires pour cela.

Essayez-le dans votre application

Dev Proxy intercepte les demandes de votre application aux API que vous choisissez et retourne 429s, avec les propres en-têtes et le format d’erreur de l’API, tandis que votre application continue d’appeler les URL réelles. Il vous indique également quand votre application réessaie avant l’expiration du délai Retry-After.

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"
API Preset
GitHub github-rate-limiting
OpenAI openai-throttling
Anthropic anthropic-throttling
Microsoft Graph (OneDrive et SharePoint : /drive, /shares, /sites) microsoft-graph-rate-limiting

Exécutez ensuite votre application comme d’habitude et regardez ce qu’elle fait. Pour installer Dev Proxy, consultez Configurer Dev Proxy.

Étapes suivantes

Tester si mon application gère correctement la limitation de requêtes

Voir aussi

  • Dernière mise à jour :