Håndter hastighedsgrænser og serverfejl

Håndter et 429-svar

En begrænset anmodning får 429 Too Many Requests med rate_limit_exceeded i detail.status. Læs svarheaderne før et nyt forsøg:

• Retry-After angiver den mindste ventetid i sekunder.
• X-RateLimit-Limit angiver spandens grænse.
• X-RateLimit-Remaining angiver resterende anmodninger.
• X-RateLimit-Reset angiver tidspunktet for nulstilling.

Vent i henhold til Retry-After, og prøv derefter igen med eksponentiel backoff og tilfældig spredning. Reducer parallelle anmodninger, og sæt arbejde i kø i stedet for at sende en bølge, så snart tidsvinduet nulstilles.

Håndter serverfejl

Ved 500 indeholder det offentlige svar en generel fejl og et request_id, ikke interne undtagelsesdetaljer. 503 kan betyde, at en påkrævet tjeneste midlertidigt er utilgængelig.

Prøv læseanmodninger igen med en begrænset backoff. Før du gentager en oprettelse, opdatering, betaling eller anden anmodning, der ændrer tilstand, skal du undersøge, om første forsøg blev gennemført. Timeout eller 5xx beviser ikke, at ændringen fejlede; en øjeblikkelig gentagelse kan fordoble arbejdet.

Bevar fejldata

Registrer tidsstempel, metode, sti, status, svarindhold og X-Request-Id. Log aldrig værdien af x-api-key. Stop automatiske gentagelser efter et lille afgrænset antal forsøg, og gør fejlen synlig til vurdering.