429-, 414-, 499-, 405-Fehler – Fehlermeldungen bei fehlgeschlagenem API-Aufruf

API-Aufrufe schlagen manchmal aufgrund extrem hoher Verkehrslasten fehl. Dies ist insbesondere dann der Fall, wenn mehrere Aufrufe pro Sekunde gleichzeitig und kontinuierlich über einen längeren Zeitraum gesendet werden. Nehmen wir beispielsweise und der mathematischen Einfachheit halber an, dass die API Aufrufe mit einer Rate von 10 Datensätzen pro Sekunde sendet und die Rückantwort lautet, dass 5 Aufrufe erfolgreich zurückgegeben wurden, was bedeutet, dass 5 dieser Aufrufe fehlgeschlagen sind: entweder beim Senden, beim Empfangen oder bei der Beantwortung durch den Server, oder D – alles zusammen.

*Hinweis: Dies ist einer der Gründe, warum empfohlen wird, nicht unaufhörlich mehrere Aufrufe pro Sekunde zu senden, sondern die Aufrufe als Best Practice um eine oder zwei Sekunden oder länger zu staffeln. 

Ein Endbenutzer kann von jedem Server, Browser und jeder Anwendung eine 429-Fehlermeldung erhalten. Abhängig vom verwendeten Betriebssystem / Browser kann die Meldung leicht variieren:

1. 429-Fehler
2. HTTP 429
3. Fehler 429 (Zu viele Anfragen)

*Da sie alle „429“ gemeinsam haben, werden diese Fehler am häufigsten als 429er bezeichnet.

429-Fehler und sein Freund, der 414-Fehler 

Alle Endbenutzer müssen Instanzen von 429-Fehlern auf Grundlage des von ihrer Organisation festgelegten Protokolls behandeln. 429-Fehler werden nicht von der Anwendung auferlegt, sondern sind vielmehr das Ergebnis des Verhaltens, das diese Fehlermeldung ausgelöst hat. Es ist wichtig zu beachten, dass dies kein Fehler der Anwendung oder des Servers ist und daher nicht von außen behoben werden kann. 

In den einfachsten Worten ausgedrückt sind 429-Fehler Signale für eine Ratenbegrenzung, die der Endbenutzer beachten muss. Ratenbegrenzungen sind anwendungsübergreifend nicht universell und auch nicht unveränderlich festgelegt, weshalb sie nur vom Endbenutzer in Bezug auf die Instanz behandelt werden können, die den 429-Fehler ausgelöst hat. 

Nachdem wir nun 429 verstanden haben, sprechen wir über 414-Fehler 

Es ist nicht ungewöhnlich, dass 429-Fehler von 414-Fehlern begleitet werden, die häufig als „URL Request Too Long“ (URL & URI) angezeigt werden. Wenn Ihre API-Aufrufe mit einer Rate gesendet werden, bei der sie nicht rechtzeitig genug beantwortet werden können, sind 414-Fehler häufig die Folge. Die URL war zu lang oder die Kombination aus Volumen und Geschwindigkeit führte dazu, dass nicht schnell genug geantwortet werden konnte. 

499 Client Closed Request 

HTTP-Statuscode 499: Ein nicht standardisierter Statuscode, der von Nginx eingeführt wurde und zurückgegeben wird, wenn der Client die Verbindung schließt, bevor der Server die Anfrage beantworten konnte, meistens verursacht durch ein clientseitiges Timeout (Endbenutzer). Tritt auf, wenn ein Client die Verbindung schließt, während Nginx die Anfrage verarbeitet. 

Die 4XX-Klasse von Codes wird häufig als Client-Fehlercodes bezeichnet. Das HTTP + 4 + XX ist ein Hinweis darauf, dass der Client (Endbenutzer) etwas falsch gemacht hat. Genauer gesagt liegt ein Fehler auf der Clientseite vor.  

Das wunderbare Entwicklungsteam von L2L hilft bei der Diagnose und Fehlerbehebung dieses Problems. Die Behebung von 429-Fehlern wird die erste Empfehlung sein und den Prozess, wieder auf die Beine zu kommen, erheblich beschleunigen! 

Wenn Sie mehr darüber lesen möchten, finden Sie hier einen Artikel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429

Fehler 405: Methode nicht erlaubt

Der Antwortstatuscode 405 „Methode nicht erlaubt“ des Hypertext-Übertragungsprotokolls (HTTP) zeigt an, dass der Server die Anfragemethode kennt, die Zielressource diese Methode jedoch nicht unterstützt.