Hantera hastighetsbegränsningar och serverfel

Hantera ett 429-svar

En hastighetsbegränsad begäran returnerar 429 Too Many Requests med detail.status satt till rate_limit_exceeded. Läs svarshuvudena innan du försöker igen:

• Retry-After anger minsta väntetid i sekunder för en avvisad begäran.
• X-RateLimit-Limit visar gränsen för begränsningsgruppen.
• X-RateLimit-Remaining visar hur många begäranden som återstår.
• X-RateLimit-Reset visar när begränsningsgruppen återställs.

Vänta enligt Retry-After och försök sedan igen med exponentiell backoff och jitter. Minska antalet parallella begäranden och köa arbetet i stället för att skicka en anstormning så snart tidsfönstret återställs.

Hantera serverfel

Vid ett 500-svar innehåller den publika svarskroppen ett allmänt fel och en request_id; interna undantagsdetaljer returneras inte. Ett 503 kan betyda att en nödvändig tjänst tillfälligt inte är tillgänglig.

Upprepa begäranden som endast läser data med en begränsad väntetid. Innan du försöker igen med en begäran som skapar, uppdaterar, betalar eller på annat sätt ändrar tillstånd behöver du ta reda på om det första försöket slutfördes. En timeout eller ett 5xx-svar bevisar inte att ändringen misslyckades, och en omedelbar upprepning kan skapa dubbelt arbete.

Spara felsökningsuppgifter

Spara tidsstämpel, metod, sökväg, status, svarskropp och X-Request-Id. Logga aldrig värdet för x-api-key. Stoppa automatiska återförsök efter ett litet och begränsat antal försök och visa felet för granskning.