HTTP-Statuscodes: Die vollständige Entwicklerreferenz (2026)

HTTP-Statuscodes sind kein Lernstoff für die Prüfung

Jede HTTP-Antwort trägt einen dreistelligen Statuscode. Die meisten Entwickler kennen die Grundlagen — 200 heißt gut, 404 heißt fehlt, 500 heißt kaputt. Aber das vollständige Bild ist interessanter und nützlicher als das.

HTTP-Statuscodes wirklich zu verstehen bedeutet, bessere APIs zu schreiben, schneller zu debuggen und intelligentere Entscheidungen bei Redirects, Caching und Fehlerbehandlung zu treffen. Dieser Leitfaden ist eine praktische Referenz, kein RFC-Dump.

Beim Arbeiten schnell einen Code nachschlagen? Das HTTP Status Codes Tool gibt dir sofort Beschreibungen und Verwendungshinweise.

---

Die fünf Kategorien: Ein mentales Modell

HTTP-Statuscodes sind in fünf Klassen gruppiert. Die erste Ziffer zeigt die Kategorie:

Bereich	Kategorie	Kurzfassung
1xx	Informational	„Moment, ich arbeite noch..."
2xx	Success	„Hier, bitte."
3xx	Redirection	„Es ist dort drüben."
4xx	Client Error	„Du hast etwas falsch gemacht."
5xx	Server Error	„Wir haben etwas falsch gemacht."

Diese Taxonomie ist es wert, verinnerlicht zu werden. Bei einem unbekannten Statuscode sagt dir die erste Ziffer sofort, ob du in der Anfrage oder auf dem Server suchen sollst.

---

2xx: Erfolgscodes

Das sind die Codes, die du sehen willst. Aber sie sind nicht alle gleich.

200 OK

Der Standard-Erfolgscode. Die Anfrage hat funktioniert, hier ist der Response-Body. Für GET-Anfragen und für POST/PUT, wenn du die aktualisierte Ressource zurückgibst.

201 Created

Wird verwendet, wenn eine Ressource erfolgreich erstellt wurde — typischerweise als Antwort auf POST. Best Practice ist, einen Location-Header mit dem Pfad zur neuen Ressource mitzugeben.

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "Anna Müller", "email": "anna@beispiel.de"}'
# HTTP/2 201
# Location: /users/43

Viele APIs geben für alles 200 zurück. Das funktioniert, ist aber faul. 201 mit Location-Header zu verwenden gibt Client-Entwicklern einen klareren Vertrag.

204 No Content

Die Anfrage war erfolgreich, aber es gibt nichts zurückzugeben. Perfekt für DELETE-Operationen oder PUT/PATCH, wenn du die aktualisierte Ressource nicht zurückgeben musst.

Sende niemals einen Body bei 204. Wenn du nach dem Löschen Daten zurückgeben musst, verwende stattdessen 200.

---

3xx: Redirects

Hier machen Entwickler die teuersten Fehler — wegen der SEO- und Caching-Auswirkungen.

301 Moved Permanently

Die Ressource ist dauerhaft zur neuen URL umgezogen. Browser cachen diesen Redirect unbegrenzt. Suchmaschinen übertragen den Linkwert (PageRank) auf die neue URL.

Achtung: Ein einmal gecachter 301 ist sehr schwer rückgängig zu machen. Browser können ihn monatelang cachen. Wenn du nicht 100% sicher bist, verwende 302.

302 Found

Temporärer Redirect. Browser folgen ihm, cachen ihn aber nicht dauerhaft. SEO-Wert bleibt bei der ursprünglichen URL. Für A/B-Tests, Wartungsseiten und Login-Redirects.

307 / 308

307 ist die methodenerhaltende Version von 302 (temporär), 308 die methodenerhaltende Version von 301 (permanent). Bei einem POST-Redirect stellt dies sicher, dass die Methode nicht zu GET wechselt.

304 Not Modified

Der Client hat eine bedingte GET-Anfrage gesendet, und die gecachte Version ist noch gültig. Server sendet nur den Statuscode, keinen Body. So funktioniert HTTP-Caching effizient.

---

4xx: Client-Fehler

Der Client hat etwas Falsches gesendet. Hier findet das meiste API-Debugging statt.

400 Bad Request

Ein Auffangcode für fehlerhafte Anfragen — fehlende Pflichtfelder, ungültiges JSON, Typfehler. Sei im Response-Body so präzise wie möglich.

{
  "error": "validation_failed",
  "details": [
    { "field": "email", "message": "Bitte eine gültige E-Mail-Adresse eingeben" },
    { "field": "age", "message": "Muss eine positive ganze Zahl sein" }
  ]
}

401 Unauthorized

Die Anfrage erfordert Authentifizierung, aber der Client hat sie nicht bereitgestellt oder ungültige Anmeldedaten gesendet. Trotz des Namens „Unauthorized" geht es hier um Authentifizierung, nicht um Autorisierung.

403 Forbidden

Der Client ist authentifiziert, hat aber keine Berechtigung auf die Ressource zuzugreifen. Der Server weiß, wer du bist — er lässt dich einfach nicht rein.

Wichtige Unterscheidung:

• Versuch auf fremde private Daten zuzugreifen → 403
• API ohne Token aufrufen → 401
• Endpunkt aufrufen, der nicht im Abonnement enthalten ist → 403

404 Not Found

Die Ressource existiert nicht. Manche APIs geben 404 zurück, auch wenn die Ressource existiert, der Nutzer aber keine Berechtigung hat — um zu vermeiden, dass die Existenz der Ressource preisgegeben wird. Dies ist für sicherheitssensible Ressourcen legitim.

409 Conflict

Die Anfrage kollidiert mit dem aktuellen Zustand der Ressource. Klassische Anwendungsfälle: Benutzer mit bereits vorhandener E-Mail-Adresse erstellen, oder Optimistic-Locking-Konflikt.

422 Unprocessable Entity

Die Anfrage ist syntaktisch korrekt (parsebares JSON, richtiger Content-Type), aber semantisch ungültig — sie verletzt Geschäftsregeln. Viele moderne APIs bevorzugen 422 gegenüber 400 für Validierungsfehler.

• 400: „Ich kann nicht einmal parsen, was du gesendet hast"
• 422: „Ich habe es geparst, aber es ergibt keinen Sinn"

429 Too Many Requests

Rate-Limit erreicht. Antwort sollte Retry-After und X-RateLimit-*-Header enthalten.

418 I'm a Teapot

Als April-Scherz in RFC 2324 definiert — das Hyper Text Coffee Pot Control Protocol. Der Server weigert sich, Kaffee zu kochen, weil er eine Teekanne ist. Google gibt diesen Code tatsächlich bei bestimmten Anfragen zurück. Der beliebteste nutzlose Standard des Internets.

---

5xx: Server-Fehler

Auf Serverseite ist etwas schief gelaufen. Der Client hat nichts falsch gemacht.

500 Internal Server Error

Der generische „etwas ist kaputt"-Code. Bedeutet meist eine unbehandelte Exception. Alles loggen, nie rohe Stack-Traces in Responses exposieren, in Produktion alarmieren.

502 Bad Gateway

Der Server agierte als Gateway oder Proxy und erhielt eine ungültige Antwort vom Upstream-Server. Häufig bei nginx + Node.js, wenn der Node-Prozess abstürzt oder timeout hat.

503 Service Unavailable

Der Server kann die Anfrage vorübergehend nicht bearbeiten — überlastet oder in Wartung. Retry-After-Header sollte enthalten sein.

504 Gateway Timeout

Das Gateway hat keine rechtzeitige Antwort vom Upstream-Server erhalten. Typisches Symptom langsamer Datenbankabfragen, timeoutender externer APIs oder Lambda-Funktionen, die ihr Ausführungslimit erreicht haben.

---

HTTP-Statuscodes im REST API Design

Praktischer Spickzettel:

GET /users → 200 (Liste)

GET /users/ → 200 (gefunden), 404 (nicht vorhanden), 403 (keine Berechtigung)

POST /users → 201 (erstellt), 400/422 (Validierungsfehler), 409 (Konflikt)

PUT /users/ → 200 (aktualisiert mit Body), 204 (aktualisiert ohne Body), 404, 409

DELETE /users/ → 204 (gelöscht), 404 (nicht vorhanden)

Konsistenz ist entscheidend

Die schlimmsten APIs sind inkonsistente APIs. Lege fest, ob du 400 oder 422 für Validierungsfehler verwendest, ob du nach Updates die Ressource zurückgibst (200) oder nicht (204) — und halte das überall durch.

Nicht alles 200 zurückgeben

Manche APIs geben {"success": false, "error": "not found"} mit HTTP 200 zurück. Das bricht Client-Bibliotheken, erschwert Monitoring und ignoriert einen perfekt guten Standard. Verwende die richtigen Statuscodes.

---

Fazit

HTTP-Statuscodes sind ein Kommunikationsprotokoll zwischen Client- und Server-Entwicklern. Sie korrekt einzusetzen ist eine Form von professioneller Höflichkeit — es macht jedem die Arbeit leichter, vom Frontend-Entwickler bis zum On-Call-Engineer um 2 Uhr nachts.

Das HTTP Status Codes Tool als Lesezeichen speichern lohnt sich für schnelle Nachschläge während der Arbeit.