Status Code (HTTP)

Die wichtigsten 10:

• 200 OK: Alles gut.
• 201 Created: Ressource angelegt (nach POST).
• 204 No Content: Erfolg, aber nix zu sagen (nach DELETE).
• 301 Moved Permanently: Alte URL ist tot, nutze die neue (gut für SEO).
• 302 Found: Temporär woanders.
• 400 Bad Request: Du hast Quatsch gesendet (JSON kaputt).
• 401 Unauthorized: Wer bist du? (Login fehlt).
• 403 Forbidden: Ich kenne dich, aber du darfst hier nicht rein.
• 404 Not Found: Gibt's nicht.
• 500 Internal Server Error: Der Code ist gecrasht (NullPointerException).
• 503 Service Unavailable: Server ist überlastet oder rebootet gerade.
• 504 Gateway Timeout: Datenbank hat zu lange gebraucht.

1. 401 vs 403

Verwechslungsgefahr.

• 401: Authentication failed. "Bitte logge dich ein." Header WWW-Authenticate muss dabei sein. (Der Türsteher lässt dich nicht rein, weil du keinen Ausweis hast).
• 403: Authorization failed. "Du bist eingeloggt, aber hast keine Admin-Rechte." (Der Türsteher lässt dich rein, aber nicht in den VIP-Bereich). Ein erneuter Login hilft hier nicht.

2. Teapot (418)

Ein April-Scherz der IETF (RFC 2324). "Hyper Text Coffee Pot Control Protocol". Server antwortet 418 I'm a teapot: "Ich kann keinen Kaffee kochen, ich bin eine Teekanne." Google hat echte Teapots im Googleplex, die darauf reagieren. Zeigt, dass Status Codes erweiterbar sind.

3. Monitoring & SLOs

SREs (Site Reliability Engineers) definieren Alerts auf Basis von Codes.

• 2xx/3xx Rate: Traffic.
• 4xx Rate: User-Fehler (steigt oft nach API Change -> Clients sind inkompatibel).
• 5xx Rate: Alarm! PagerDuty ruf an. Server brennen. SLO (Service Level Objective): "99.9% aller Requests müssen fehlerfrei (nicht 5xx) sein in 30 Tagen."

1. 103 Early Hints (Performance-Boost)

Ein relativ neuer Status Code (RFC 8297). Normalerweise wartet der Browser, bis der Server die komplette HTML-Seite generiert hat (Status 200), bevor er anfängt, CSS oder JS zu laden. Bei 103 Early Hints schickt der Server sofort die Header mit den Links zu den Ressourcen raus, noch während er im Hintergrund an der schweren SQL-Abfrage für das HTML bastelt. Der Browser kann so schon mal anfangen zu laden, während der Server noch "denkt". Das verbessert die Ladezeit (LCP) massiv.

2. 422 Unprocessable Entity (Die API-Wahl)

In modernen REST APIs (besonders im Zusammenspiel mit Frameworks wie Laravel oder Rails) ist 422 der Standard für Validierungsfehler. Unterschied zu 400 (Bad Request):

• 400: Das Paket ist kaputt (JSON fehlt, Syntaxfehler). Der Server kann es gar nicht lesen.
• 422: Das JSON ist syntaktisch korrekt, aber die Daten machen keinen Sinn (z.B. "E-Mail-Adresse fehlt" oder "Alter ist negativ"). Es ist semantisch präziser als ein allgemeines 400, da es besagt: "Ich hab dich verstanden, aber ich kann mit diesem Inhalt nicht arbeiten."

3. Fehler-Diagnose via Custom Headers

Status Codes sind oft zu grob. "500" heißt nur "Kaputt". Um das Debugging in großen Systemen zu erleichtern, senden APIs oft zusammen mit dem Status Code eine Request-ID oder einen Error-Link im Header oder Body. Standard-Vorschläge wie Problem Details for HTTP APIs (RFC 7807) definieren ein festes JSON-Format für Fehlermeldungen:

{
  "type": "https://example.com/probs/out-of-credit",
  "title": "You do not have enough credit.",
  "status": 403,
  "detail": "Your current balance is 30, but that costs 50.",
  "instance": "/account/12345/msgs/abc"
}

Das erlaubt es dem Frontend, dem User eine hilfreiche Nachricht zu zeigen ("Guthaben aufladen"), statt nur ein generisches "Fehler 403".