429 Zbyt wiele żądań: co to znaczy i jak je obsłużyć

Interfejs API zwraca wartość 429 Too Many Requests , gdy aplikacja wysłała więcej żądań, niż interfejs API zezwala w danym okresie. Samo żądanie jest w porządku. Wysłałeś go zbyt często, więc interfejs API go odrzucił. Jeśli zaczekasz i wyślesz go ponownie, zwykle zakończy się to powodzeniem. Odpowiedź często zawiera Retry-After nagłówek, który informuje, jak długo czekać. Aby uzyskać więcej informacji, zobacz RFC 6585, sekcja 4.

Każdy interfejs API implementuje limity szybkości w inny sposób. Kod stanu, nagłówki i treść błędu różnią się, przez co kod obsługujący jeden interfejs API może nieprawidłowo obsłużyć następny.

API Status Jak sprawdzić, jak długo czekać Uważaj na
GitHub 403 lub 429 retry-after jeśli jest obecny, w przeciwnym razie x-ratelimit-reset (sekundy epoki UTC), gdy x-ratelimit-remaining jest 0, w przeciwnym razie co najmniej 1 minuta Może 403 to być limit szybkości lub brakujące uprawnienie. Przeczytaj nagłówki, aby je odróżnić.
Otwarta sztuczna inteligencja 429 retry-after Niektóre 429, takie jak credit_balance_exhausted, oznaczają, że ponawianie nie pomoże. Sprawdź error.code.
Antropiczny 429 retry-after Błąd 429 związany z limitem wydatków nie ma retry-after i nadal kończy się niepowodzeniem do czasu wznowienia dostępu. Przeciążony interfejs API zwraca wartość 529, a nie 429.
Microsoft Graph 429 Retry-After (sekundy) Limity różnią się w zależności od usługi, na przykład SharePoint i Outlook.

Jak obsłużyć 429

  1. Zdecyduj, czy w ogóle ponowić próbę. Jeśli błąd wskazuje, że limit przydziału, kredytów lub wydatków został wyczerpany, ponawianie próby nie pomoże. Poinformuj użytkownika i ustaw sobie alert.
  2. Zaczekaj tak długo, jak wymaga tego interfejs API. Jeśli odpowiedź zawiera Retry-After, poczekaj tak długo. Jest to liczba sekund lub data HTTP. Jeśli interfejs API używa nagłówków limitu szybkości, takich jak GitHubx-ratelimit-reset, zaczekaj na czas resetowania.
  3. W przeciwnym razie wycofaj się. Bez wskazówki z interfejsu API spróbuj ponownie z wykładniczo wydłużanym czasem ponawiania i losowymi zakłóceniami i zatrzymaj się po kilku próbach.
  4. Poinformuj użytkownika o tym, co się dzieje. „Zajęty, ponawianie próby w ciągu 5 sekund” jest lepsze niż wskaźnik ładowania, który nigdy się nie kończy.
  5. Zwolnij przed następnym błędem 429. Jeśli interfejs API wysyła nagłówki limitu szybkości, użyj pozostałej liczby, aby odpowiednio rozłożyć żądania w czasie.
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)));
  }
}

Wiele zestawów SDK automatycznie ponawia dla Ciebie żądania zakończone błędem 429. Na przykład zestaw OpenAI Python SDK domyślnie ponawia próbę 2 razy, a .NET standardowy moduł obsługi odporności ponawia próbę 3 razy i honoruje Retry-After. Gdy zestaw SDK wyczerpie limit ponowień, kod otrzymuje błąd, więc nadal wymaga planu.

Jak przetestować, czy aplikacja obsługuje kod 429

Rzadko widzisz 429 podczas programowania. Interfejs API jest szybki, jesteś jedynym użytkownikiem, a dane testowe są małe. Dlatego sposób testowania obsługi 429 decyduje, czy znajdziesz usterki, zanim zrobią to użytkownicy.

Approach Co znajdziesz Czego ci brakuje
Czekaj na produkcję Rzeczywiste awarie Wszystko, dopóki użytkownik go nie kliknie
Mockuj interfejs API w testach lub pozwól agentowi programistycznemu napisać mock Czy gałąź ponowienia jest wykonywana Rzeczywiste kody stanu, nagłówki i treści odpowiedzi o błędach interfejsu API oraz zasady ponawiania prób zestawu SDK. Aplikacja wymaga również przełącznika tylko do testowania, aby połączyć się z mockiem.
Wywołuj rzeczywiste API, dopóki API nie zacznie ograniczać żądań Rzeczywiste zachowanie Nie można wyzwolić 429 na żądanie i zużywasz swój rzeczywisty limit przydziału
Przechwytuj rzeczywisty ruch aplikacji i zwracaj 429 na żądanie Rzeczywiste adresy URL, prawdziwy zestaw SDK i zasady ponawiania prób oraz własny format 429 interfejsu API W Twojej aplikacji nic się nie zmienia, więc nie testuje Twojego kodu w izolacji. Do tego służą testy jednostkowe.

Wypróbuj ją w aplikacji

Dev Proxy przechwytuje żądania aplikacji do wybranych interfejsów API i zwraca kod 429 z własnymi nagłówkami interfejsu API oraz formatem błędów, podczas gdy aplikacja nadal wywołuje rzeczywiste adresy URL. Informuje również, kiedy aplikacja ponawia próbę, zanim upłynie Retry-After czas.

Pobierz preset interfejsu API, które wywołuje Twoja aplikacja, i uruchom Dev Proxy za jego pomocą:

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 i SharePoint: /drive, /shares, /sites) microsoft-graph-rate-limiting

Następnie uruchom aplikację jak zwykle i obserwuj, co robi. Aby zainstalować Dev Proxy, zobacz Set up Dev Proxy.

Następne kroki

Przetestuj, czy moja aplikacja prawidłowo obsługuje ograniczanie przepustowości

Informacje dodatkowe

  • Ostatnia aktualizacja o