Was ist HTTP-Statuscode-Nachschlagewerk?
HTTP-Statuscodes sind die dreistelligen Zahlen, die ein Webserver mit jeder Antwort zurücksendet, um dem Client (Browser, App oder API-Consumer) mitzuteilen, ob die Anfrage erfolgreich war, eine Weiterleitung benötigt oder fehlgeschlagen ist – und warum. Sie sind von der IETF standardisiert und werden bei jedem Webserver, Browser und in jeder Programmiersprache identisch verwendet, was sie zu einer der universellsten Debugging-Referenzen der Softwareentwicklung macht.
Dieses Nachschlagewerk deckt die am häufigsten anzutreffenden Codes aus allen fünf Kategorien ab – informativ (1xx), Erfolg (2xx), Weiterleitung (3xx), Client-Fehler (4xx) und Server-Fehler (5xx) – mit verständlichen Erklärungen, was jeder davon in der Praxis tatsächlich bedeutet, nicht nur die formale RFC-Definition.
Wann Sie diesen Rechner verwenden
- Debuggen einer API-Integration, bei der eine Anfrage fehlschlägt und Sie verstehen müssen, was der Statuscode tatsächlich bedeutet
- Entscheiden, welchen Statuscode Ihre eigene API für eine bestimmte Fehlerbedingung zurückgeben soll
- Unterrichten oder Erlernen der HTTP-Grundlagen in einem Webentwicklungskurs oder Bootcamp
- Schreiben von Fehlerbehandlungs-Middleware, die zwischen verschiedenen 4xx- und 5xx-Fällen unterscheiden muss
- Untersuchen, warum eine Weiterleitung nicht funktioniert, indem geprüft wird, ob 301 oder 302 zurückgegeben wurde
- Beheben von CORS-Problemen, bei denen der Browser einen Netzwerkfehler anzeigt, der Server aber 200 zurückgegeben hat
Schritte:
- Geben Sie einen Statuscode (wie 404) oder ein Stichwort (wie „forbidden“) in das Suchfeld ein.
- Filtern Sie über die 1xx-5xx-Schaltflächen nach Kategorie, wenn Sie einen bestimmten Bereich durchsuchen möchten.
- Lesen Sie die verständliche Beschreibung, was der Code bedeutet und wann er typischerweise zurückgegeben wird.
- Nutzen Sie dies als schnelle Referenz beim Debuggen von API-Antworten oder beim Erstellen von Fehlerbehandlung.
Formel
1xx: Informativ — Anfrage empfangen, Verarbeitung wird fortgesetzt
2xx: Erfolg — Anfrage wurde erfolgreich empfangen und akzeptiert
3xx: Weiterleitung — weitere Aktion nötig, um die Anfrage abzuschließen
4xx: Client-Fehler — Anfrage enthält fehlerhafte Syntax oder kann nicht erfüllt werden
5xx: Server-Fehler — Server konnte eine gültige Anfrage nicht erfüllen
Anwendungsfälle
- Schnelles Verstehen eines unbekannten Statuscodes, den eine API zurückgibt, die Sie integrieren
- Entscheiden, welchen Statuscode Ihre eigene API für eine bestimmte Fehlerbedingung zurückgeben soll
- Debuggen, warum eine Anfrage fehlschlägt, indem geprüft wird, was ein bestimmter Code tatsächlich bedeutet
- Unterrichten oder Erlernen der HTTP-Grundlagen in einem Webentwicklungskurs
- Schreiben präziser Fehlerbehandlungslogik, die zwischen verschiedenen 4xx- und 5xx-Fällen unterscheidet
Hauptvorteile
- Jeder gängige Statuscode in einer durchsuchbaren Referenz
- Verständliche Erklärungen, nicht nur formaler RFC-Wortlaut
- Sofortiges Filtern nach Kategorie (1xx bis 5xx)
- Kostenlos, schnell, keine Anmeldung erforderlich
Professionelle Tipps
- Reservieren Sie 5xx-Codes strikt für serverseitige Fehler – verwenden Sie sie niemals, um Client-Eingabefehler zu signalisieren
- Verwenden Sie 429 mit einem Retry-After-Header bei Ratenbegrenzung, damit sich korrekt verhaltende Clients wissen, wann sie es erneut versuchen sollen
- Bevorzugen Sie 404 gegenüber einer generischen Fehlerseite, wenn eine Ressource tatsächlich nicht existiert – das ist sowohl für Nutzer als auch für Suchmaschinen besser
- Wählen Sie beim API-Design spezifische 4xx-Codes (422, 409, 400), statt standardmäßig alles auf einen generischen 400 zurückzuführen
Häufige Fehler vermeiden
- Rückgabe von 200 OK für eine Anfrage, die tatsächlich fehlgeschlagen ist, wodurch Fehler vor Monitoring-Tools verborgen werden
- Verwechseln von 401 (nicht authentifiziert) mit 403 (authentifiziert, aber nicht autorisiert)
- Verwenden von 302 für eine Weiterleitung, die permanent (301) sein sollte, was der SEO schadet
- Behandeln aller 4xx- und 5xx-Fehler gleich in der clientseitigen Fehlerbehandlung, statt nach dem konkreten Code zu unterscheiden
Wichtige Begriffe erklärt
- Statuszeile: Die erste Zeile einer HTTP-Antwort, die den Statuscode und eine kurze Begründung enthält
- Idempotent: Eine Eigenschaft bestimmter HTTP-Methoden, bei denen die Wiederholung derselben Anfrage die gleiche Wirkung hat wie einmalige Ausführung
- Weiterleitungskette: Eine Abfolge mehrerer Weiterleitungen, denen ein Browser folgt, bevor er die endgültige Ressource erreicht
- Ratenbegrenzung: Beschränkung, wie viele Anfragen ein Client in einem bestimmten Zeitfenster stellen darf, oft mit 429 signalisiert
Verwandte Konzepte
- JSON-Formatter
- JSON-Validator
- Regex-Tester
- URL-Encoder/Decoder
- Base64-Encoder/Decoder
Beispiel
Die Suche nach „429“ liefert „Too Many Requests“ – der Code, den APIs zurückgeben, wenn Sie ein Ratenlimit überschritten haben, und der Ihnen mitteilt, langsamer zu werden und nach einer Verzögerung erneut zu versuchen.
Interpretation Ihrer Ergebnisse
HTTP-Statuscodes werden anhand ihrer ersten Ziffer in fünf Klassen eingeteilt. 1xx sind informativ und im Anwendungscode selten zu sehen. 2xx bestätigen Erfolg — 200 OK ist der häufigste, aber 201 Created und 204 No Content kommen in REST-APIs ebenfalls häufig vor. 3xx behandeln Weiterleitungen, wobei 301 (dauerhaft) und 302 (temporär) am wichtigsten sind.
4xx-Fehler zeigen an, dass mit der Client-Anfrage etwas nicht stimmt. Die häufigsten sind 400 Bad Request (fehlerhafte Syntax), 401 Unauthorized (nicht authentifiziert), 403 Forbidden (nicht autorisiert), 404 Not Found (Ressource existiert nicht) und 429 Too Many Requests (Ratenlimit überschritten). Die korrekte Verwendung spezifischer 4xx-Codes macht Ihre API wesentlich besser debugbar, als für alles ein generisches 400 zurückzugeben.
5xx-Fehler bedeuten, dass der Server versagt hat. 500 ist der Auffangcode für interne Fehler, 502 Bad Gateway deutet auf ein Problem mit einem vorgelagerten Server hin, und 503 Service Unavailable bedeutet meist, dass der Server überlastet oder wegen Wartung nicht verfügbar ist. Beim Debuggen von 5xx-Fehlern prüfen Sie die Server-Logs statt der Client-Antwort, da der Statuscode allein die Ursache selten aufdeckt.