HTTP-Statuscodes sind nach ihrer ersten Ziffer in fünf Klassen gruppiert, und den richtigen zu wählen lässt Clients korrekt reagieren, ohne den Body zu parsen.
2xx Success — the request worked
3xx Redirection — further action / resource moved
4xx Client error — the caller did something wrong
5xx Server error — the server failed
2xx
200 OK — allgemeiner Erfolg (GET, PUT, PATCH).201 Created — eine Ressource wurde erstellt (gib einen Location-Header zurück).202 Accepted — zur asynchronen Verarbeitung angenommen, noch nicht fertig.204 No Content — Erfolg ohne Body (verbreitet bei DELETE).4xx
400 Bad Request — fehlerhafte Syntax oder ungültige Eingabe.401 Unauthorized — nicht authentifiziert (keine/ungültige Credentials).403 Forbidden — authentifiziert, aber nicht erlaubt.404 Not Found — Ressource existiert nicht.409 Conflict — Konflikt mit dem aktuellen Zustand (z. B. doppelte E-Mail).422 Unprocessable Entity — wohlgeformt, aber Validierung schlägt fehl.429 Too Many Requests — Rate-limitiert.5xx
500 Internal Server Error — ein unerwarteter Serverfehler.503 Service Unavailable — vorübergehend nicht verfügbar/überlastet.POST /users → 201 Created
Location: /users/42
DELETE /users/42 → 204 No Content
GET /users/999 → 404 Not Found
{ "error": "user not found" }
Die zentrale Unterscheidung, die Interviewer sondieren: 401 ("wer bist du?") vs. 403 ("ich kenne dich, aber nein"), und 400 (fehlerhafte Syntax) vs. 422 (gültige Syntax, ungültige Daten).
Statuscodes sind das primäre Signal in einer REST-Response — Clients, Proxies, Monitoring und Retry-Logik richten sich alle danach, daher ist es essenziell für Interoperabilität, sie richtig zu setzen. Ein häufiges Versagen ist, 200 OK mit einem { "error": ... }-Body zurückzugeben: es zwingt jeden Client, den Body zu parsen, um zu wissen, ob der Call erfolgreich war, bricht generisches HTTP-Tooling und verbirgt Fehler vor dem Monitoring. Präzise Codes treiben auch automatisches Verhalten an: ein 429 oder 503 sagt einem gut gebauten Client, zurückzuweichen und erneut zu versuchen, während ein 4xx sagt "nicht wiederholen, den Request korrigieren". Interviewer nutzen diese Frage, um zu prüfen, ob du HTTP als Vertrag statt als dummen Transport verstehst und ob du die subtilen Paare (401/403, 400/422) korrekt unterscheidest — ein Kennzeichen von jemandem, der echte APIs gebaut und konsumiert hat.
Eine Sammlung von IT-Interviewfragen mit ausführlichen Antworten — vom Junior bis zum Senior.
Spenden