HTTP Statusklassen 2xx und 4xx

Dieser Beitrag ist eine Begriffserklärung zu den wichtigsten 2xx- und 4xx-Statuscodes – inklusive Prüfungsfragen und Tags.

In a Nutshell

2xx signalisiert erfolgreiche Verarbeitung. 4xx kennzeichnet Clientfehler. Korrekte Codes verbessern Verständlichkeit, Caching, Idempotenz und robuste APIs.

Kompakte Fachbeschreibung

Typische 2xx:

• 200 OK (lesen/erfolgreich)
• 201 Created + Location (Ressource erstellt)
• 202 Accepted (asynchron gestartet)
• 204 No Content (kein Body)

Typische 4xx:

• 400 Bad Request (syntaktisch/validierung)
• 401 Unauthorized (fehlende Auth)
• 403 Forbidden (keine Berechtigung)
• 404 Not Found
• 409 Conflict (Konflikt)
• 422 Unprocessable Content (semantisch ungültig)
• 429 Too Many Requests (Rate Limit) + Retry-After

Einheitliche Fehlerobjekte nach RFC 7807 (Problem Details) erleichtern Debugging und Doku.

Prüfungsrelevante Stichpunkte

• 201 immer mit Location
• 204 nur, wenn wirklich kein Body
• 202 + Status-Endpunkt (Location) für Async
• 401 vs 403 sauber trennen
• 409/412 bei Parallelität/ETag
• Keine sensiblen Details in Fehlern
• In OpenAPI pro Endpoint Statuscodes dokumentieren

Kernkomponenten

1. 2xx: 200/201/202/204
2. 4xx: 400/401/403/404/409/422/429
3. Header: Location, Retry-After, ETag, Content-Type
4. Bedingte Requests (If-Match)
5. Problem Details (type/title/status/detail/instance)
6. Tests (Negativtests/Contracttests)

Praxisbeispiel

POST /orders
→ 201 Created
Location: /orders/42
ETag: W/"7c9"

PUT /orders/42 (If-Match: W/"7c9")
→ 412 Precondition Failed bei Versionskonflikt

GET /orders/9999
→ 404 Not Found

Vorteile und Nachteile

Vorteile

• Klare Semantik
• Weniger Integrationsfehler
• Besseres Caching/Retry-Verhalten

Nachteile

• Falsche Codes verwirren
• Framework-Defaults führen zu Inkonistenzen
• Mehr Sorgfalt/Tests nötig

Typische Prüfungsfragen (mit Kurzantwort)

1. Wann 201 und welcher Header? Bei Erstellung; Location zeigt neue URI.
2. 200 vs 204? 200 mit Body, 204 ohne Body.
3. 401 vs 403? 401 Auth fehlt/ungültig; 403 keine Rechte.
4. Wann 422 statt 400? JSON syntaktisch ok, aber semantisch ungültig.

Freie Antwort

Lege pro Endpoint fest: zulässige Codes, wann sie auftreten, welche Header gesetzt werden und wie Fehlerobjekte aussehen. So sinkt Supportaufwand erheblich.

Lernstrategie

1. Statuscodes einer öffentlichen API analysieren.
2. Sequenzdiagramm für 202-Workflow skizzieren.
3. Karteikarten (Code → Bedeutung → Header) üben.
4. 200 nicht „für alles“ nutzen.

Wichtigste Quellen

1. https://www.rfc-editor.org/rfc/rfc9110
2. https://developer.mozilla.org/docs/Web/HTTP/Status
3. https://www.rfc-editor.org/rfc/rfc7807