HTTP 204 No Content
Erfolg mit absichtlich leerem Body — der Request hat funktioniert, es gibt nur nichts zurückzusenden.
Was HTTP 204 bedeutet
HTTP 204 No Content signalisiert Erfolg genau wie 200, nur dass die Antwort absichtlich keinen Body hat. Es ist die idiomatische Antwort für DELETE-Requests, für PUT/PATCH-Updates, bei denen das Zurückgeben des Objekts redundant wäre, sowie für Beacon- oder Logging-Endpunkte.
Da eine 204 keinen Body enthalten darf, wirft das JSON-Parsen einer 204-Antwort im Client-Code (z. B. der Aufruf von response.json() nach fetch) einen Fehler — ein sehr verbreiteter Bug. Prüfe den Status, bevor du parst.
Häufige Ursachen von 204-Antworten
- Ein DELETE-Request hat die Ressource entfernt.
- Ein PUT oder PATCH hat eine Ressource aktualisiert, und der Server hat entschieden, sie nicht zurückzugeben.
- Ein Endpunkt, der nur Daten erfasst (Analytics-Beacons, Health-Checks), hat den Empfang bestätigt.
Gute Praktiken für Entwickler
- Sende bei 204 niemals einen Response-Body — viele Server und Proxys brechen die Verbindung ab, wenn du es doch tust.
- Prüfe im Client-Code den Status 204, bevor du .json() oder .text() aufrufst.
- Wenn Clients die aktualisierte Repräsentation brauchen, gib stattdessen 200 mit Body zurück statt 204.
Beispielantwort
HTTP/1.1 204 No Content Datum: Thu, 02 Jul 2026 10:00:00 GMT
FAQ
Was ist der Unterschied zwischen 204 und 200 mit leerem Body?
In der Praxis verhalten sie sich gleich, aber 204 ist explizit: Das Fehlen eines Bodys ist beabsichtigt, und Clients sollten nicht versuchen, einen zu parsen.
Warum schlägt response.json() bei einer 204 fehl?
Eine 204-Antwort hat überhaupt keinen Body, daher gibt es nichts zu parsen. Prüfe response.status === 204, bevor du parst.
Sollte DELETE immer 204 zurückgeben?
Es ist die häufigste Wahl. Eine 200 mit einem Bestätigungs-Body zurückzugeben ist ebenfalls gültig, wenn Clients Details darüber brauchen, was gelöscht wurde.