Eine API antwortet mit 429 Too Many Requests. Ein sofortiger erneuter Aufruf kann die Situation verschärfen. Prüfe zuerst, welche Begrenzung dokumentiert ist und ob die Antwort eine Warteinformation enthält.
Ein vereinfachtes Antwortbeispiel:
HTTP/1.1 429 Too Many Requests
Retry-After: 120
Hier beschreibt der Header eine Wartezeit in Sekunden. Retry-After kann auch als HTTP-Datum vorkommen. Verarbeite das tatsächlich verwendete Format, statt jeden Wert blind als Zahl zu behandeln.
Nicht jede Aktion automatisch wiederholen
Unterscheide einen lesenden Abruf von einer schreibenden Operation. Bei einem unklaren Ergebnis eines Schreibvorgangs kann eine Wiederholung eine doppelte Wirkung auslösen, wenn der API-Vertrag dafür keinen Schutz vorsieht. Die Antwortklasse allein beantwortet diese fachliche Frage nicht.
Plane für wiederholbare Vorgänge ein begrenztes Verhalten: Anzahl der Versuche, Wartezeit und sichtbarer Abbruch gehören zusammen. Vermeide Endlosschleifen. Mehrere parallel arbeitende Prozesse sollten nicht alle synchron erneut anfragen, wenn sie denselben Grenzwert teilen.
Teste den Ablauf gegen einen isolierten Dienst, der gezielt 429 zurückgibt. Prüfe, dass die Anwendung tatsächlich wartet, nach dem festgelegten Limit abbricht und keinen Erfolg behauptet. Lass bei einem Abbruch die betroffene Aktion erneut auswählbar und zeige den Grund an.
Dokumentiere außerdem, wer den betroffenen Zugang und sein Kontingent verwaltet. Das Erhöhen eines Limits kann Kosten oder Anbieterbedingungen berühren und ist eine andere Entscheidung als die technische Fehlerbehandlung.