429 Zu viele Anfragen: Was dies bedeutet und wie sie behandelt werden

Eine API gibt 429 Too Many Requests zurück, wenn Ihre App mehr Anfragen gesendet hat, als die API in einem bestimmten Zeitraum zulässt. Die Anforderung selbst ist in Ordnung. Sie haben sie zu oft gesendet, sodass die API sie abgelehnt hat. Wenn Sie warten und es erneut senden, ist es in der Regel erfolgreich. Die Antwort enthält häufig einen Retry-After Header, der Ihnen angibt, wie lange gewartet werden soll. Weitere Informationen finden Sie unter RFC 6585, Abschnitt 4.

Wie ein HTTP-Statuscode 429 in beliebten APIs aussieht

Jede API implementiert Ratenbegrenzungen unterschiedlich. Der Statuscode, die Header und der Fehlertext variieren alle, sodass Code, der eine API ordnungsgemäß verarbeitet, die nächste falsch behandeln kann.

So behandeln Sie einen 429-Fehler

1. Entscheiden Sie, ob Sie es überhaupt erneut versuchen möchten. Wenn der Fehler besagt, dass Ihr Kontingent, Ihr Guthaben oder Ihr Ausgabenlimit aufgebraucht ist, hilft das Wiederholen nicht. Informieren Sie den Benutzer, und lassen Sie sich benachrichtigen.
2. Warten Sie so lange, wie von der API verlangt. Wenn die Antwort lautet Retry-After, warten Sie so lange. Es ist entweder eine Anzahl von Sekunden oder ein HTTP-Datum. Wenn die API stattdessen Rate-Limit-Header verwendet, z. B. GitHubs x-ratelimit-reset, warten Sie, bis die Rücksetzzeit erreicht ist.
3. Andernfalls treten Sie zurück. Ohne einen Hinweis von der API versuchen Sie es mit exponentiellem Backoff und zufälligem Jitter, und hören Sie nach einigen Versuchen auf.
4. Teilen Sie dem Benutzer mit, was passiert. „Vorgang läuft, erneuter Versuch in 5 Sekunden“ schlägt einen Spinner, der nie endet.
5. Verlangsamen Sie sich vor dem nächsten 429-Fehler. Wenn die API Header zur Ratebegrenzung sendet, verwenden Sie die verbleibende Anzahl, um Ihre Anfragen entsprechend zu takten.

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)));
  }
}

Viele SDKs versuchen Anfragen mit 429-Fehlern für Sie erneut. Beispielsweise führt das OpenAI Python SDK standardmäßig 2 Wiederholungsversuche aus, und der .NET Standardresilienzhandler wiederholt 3 Mal und berücksichtigt Retry-After. Wenn das SDK keine Wiederholungsversuche mehr ausführt, erhält Ihr Code den Fehler, sodass er weiterhin einen Plan benötigt.

So testen Sie, dass Ihre App mit 429 umgeht

Sie sehen selten eine 429 während der Entwicklung. Die API ist schnell, Sie sind der einzige Benutzer, und Ihre Testdaten sind klein. Daher entscheidet die Art und Weise, wie Sie die Behandlung von 429 testen, ob Sie die Fehler finden, bevor Ihre Benutzer dies tun.

Probieren Sie sie in Ihrer App aus

Dev Proxy fängt die Anforderungen Ihrer App an die von Ihnen ausgewählten APIs ab und gibt 429s zurück, wobei 429-Fehler mit den eigenen Headern und dem Fehlerformat der API zurückgegeben werden, während Ihre App die echten URLs aufruft. Außerdem erfahren Sie, wann Ihre App erneut versucht, bevor die Retry-After Zeit abgelaufen ist.

Laden Sie die Voreinstellung für die API herunter, die Ihre App aufruft, und starten Sie Dev Proxy damit:

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

Führen Sie dann Ihre App wie gewohnt aus, und beobachten Sie, was sie tut. Informationen zum Installieren von Dev Proxy finden Sie unter Einrichten von Dev Proxy.

Nächste Schritte

Siehe auch

• Was ist die Zinsbegrenzung?
• Was bedeutet Drosselung?
• Testen, wie Ihre App GitHub API-Ratenbeschränkungen behandelt
• Testen, wie Ihre App OpenAI-Ratelimits behandelt
• Testen von Wiederholungen und Timeouts in .NET Apps