HTTP Statusklassen – 2xx Erfolgscodes & 4xx Clientfehler

Dieser Beitrag ist eine Begriffserklärung zu HTTP Statusklassen – inklusive Prüfungsfragen und Tags.

In a Nutshell

• 2xx: erfolgreiche Verarbeitung (200 OK, 201 Created, 202 Accepted, 204 No Content)
• 4xx: vom Client verursachte Fehler (400, 401, 403, 404, 409, 422, 429)

Kompakte Fachbeschreibung

2xx signalisiert erfolgreiche Verarbeitung einer Anfrage, 4xx kennzeichnet vom Client verursachte Fehler. 2xx umfasst typische Erfolge: 200 OK für Leseoperationen, 201 Created mit Location Header für neu angelegte Ressourcen, 202 Accepted für asynchron gestartete Vorgänge, 204 No Content wenn kein Body zurückgegeben wird. 4xx beschreibt Clientfehler: 400 Bad Request bei Validierungsfehlern, 401 Unauthorized für fehlende Authentisierung, 403 Forbidden bei fehlender Autorisierung, 404 Not Found bei unbekannter Ressource, 409 Conflict bei Versionskonflikten, 422 Unprocessable Content bei semantisch fehlerhaften Daten, 429 Too Many Requests bei Rate Limits.

Prüfungsrelevante Stichpunkte

• 201 Created immer mit Location Header auf die neue Ressource
• 204 No Content nur verwenden, wenn tatsächlich kein Body benötigt wird
• 202 Accepted für asynchrone Workflows mit nachgelagertem Status Endpunkt
• Konsistente Fehlerstruktur mit Problem Details und nachvollziehbarer Fehler-ID
• 409 Conflict bei ETag Kollisionsfällen und parallelen Updates
• 401 für fehlende Authentisierung, 403 für fehlende Berechtigung
• Saubere Codes reduzieren Supportaufwand und Integrationskosten
• Statuscodes und Fehlerobjekte pro Operation in OpenAPI beschreiben

Kernkomponenten

1. Statuslinie mit Code und Reason Phrase
2. 2xx Codes: 200, 201, 202, 204
3. 4xx Codes: 400, 401, 403, 404, 409, 422, 429
4. Header: Location, Retry After, ETag, Content-Type
5. Bedingte Requests: If-Match, If-None-Match, If-Modified-Since
6. Idempotenz Regeln pro Methode
7. Fehlerobjekte: Problem Details (type, title, status, detail, instance)
8. Paginierung bei 200 Antworten mit Links (First, Prev, Next, Last)
9. Observability: Korrelation-ID, Trace-ID, Logging
10. Testverfahren: Negativtests, Contract Tests, Retry und ETag Konflikte

Praxisbeispiel

// Anlegen einer Bestellung mit späterer Bestätigung
POST https://api.shop.de/orders
Headers: Content-Type: application/json, Idempotency-Key: abc-123
Body: { customerId: 123, items: [{ sku: "A1", qty: 2 }] }

Antwort bei sofortiger Erstellung:
Status: 201 Created
Headers: Location: https://api.shop.de/orders/42, ETag: W/"7c9"
Body: { id: 42, status: "created" }

Antwort bei asynchroner Verarbeitung:
Status: 202 Accepted
Headers: Location: https://api.shop.de/jobs/987, Retry-After: 10
Body: { jobId: 987, state: "queued" }

Konflikt durch veraltetes ETag:
PUT https://api.shop.de/orders/42
Headers: If-Match: W/"7c9"
Body: { status: "confirmed" }

Server hat neuere Version:
Status: 412 Precondition Failed
Body: application/problem+json
{ type: "https://problems/concurrency", title: "Precondition failed", status: 412, detail: "Version mismatch", instance: "/orders/42" }

Vorteile und Nachteile

Vorteile

• Klare Semantik, bessere Clientsteuerung
• Einfachere Fehlerbehandlung
• Bessere Caching-Strategien und Wiederholbarkeit
• Geringerer Supportaufwand

Nachteile

• Falsche Codes verwirren Clients
• Erschweren Caching und Retries
• Unterschiedliche Framework Defaults führen zu Inkonistenzen
• Zusätzliche Sorgfalt in Dokumentation und Tests nötig

Typische Prüfungsfragen (mit Kurzantwort)

1. Wann 201 Created und welche Header relevant? Bei Ressourcen-Neuanlage, Location zeigt auf neue URI, optional ETag für Updates.
2. Unterschied 200 OK vs. 204 No Content? 200 überträgt Repräsentation, 204 verzichtet auf Body, nutze 204 nur wenn Client keine Inhalte benötigt.
3. Asynchrone Workflows mit Statuscodes? 202 Accepted mit Status-Endpunkt im Location Header, optional Retry-After.
4. 401 vs. 403, wann welches? 401 bei fehlender/ungültiger Authentisierung, 403 bei authentisiertem Nutzer ohne Rechte.
5. 409 Conflict in REST APIs? Anwendungs-Konflikte: Versionskonflikte, doppelte Ressourcen, Geschäftsregel-Verletzungen.
6. 422 statt 400 Bad Request? 422 bei syntaktisch korrektem aber semantisch ungültigem JSON (Domänenregel-Verletzungen).
7. ETag und If-Match für sichere Updates? Client sendet If-Match, Server führt Update nur bei Tag-Übereinstimmung aus, sonst 412.
8. Idempotenz bei Statuscodes und Retries? Idempotente Methoden (PUT, DELETE) ermöglichen Retries, POST benötigt Idempotency-Key.

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