Die Anfrage ist wohlgeformt, besteht aber die Validierung nicht.
Wann du ihn verwendest
Gültiges JSON mit ungültigen Werten, etwa einem Enddatum vor dem Startdatum.
Häufige Ursachen und Lösungen
422 bedeutet, dass der Server die Syntax verstanden hat, der Inhalt aber die Validierung nicht besteht: Ein Pflichtfeld ist leer, eine E-Mail-Adresse ist fehlerhaft, ein Datumsbereich ist vertauscht oder eine referenzierte ID existiert nicht. FastAPI gibt ihn bei jedem Pydantic-Validierungsfehler zurück, und Rails und Laravel nutzen ihn bei fehlgeschlagener Model-Validierung. Rails gibt 422 außerdem bei einem ungültigen CSRF-Token zurück, was viele überrascht.
Gib Fehler pro Feld im Body zurück, damit der Client sie neben den richtigen Eingabefeldern anzeigen kann, idealerweise in einer einheitlichen Form wie RFC 9457 Problem Details. Wiederhole eine 422 nicht, ohne die Daten zu ändern. Teams sind uneins über 400 gegenüber 422; leg eine Regel fest, etwa 400 für nicht parsbare und 422 für wohlgeformte, aber ungültige Eingaben, und wende sie überall an.
Client-Fehler (4xx)
4xx-Codes sind Client-Fehler: Die Anfrage selbst ist fehlerhaft, nicht autorisiert oder verweist auf etwas, das es nicht gibt. Dieselbe Anfrage erneut zu senden hilft nicht.
So sieht es aus
HTTP/1.1 422 Unprocessable ContentSo sendest du ihn
| Node.js / Express | res.status(422).end() |
|---|---|
| Python / Flask | return '', 422 |
| nginx | return 422; |
So prüfst du ihn
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/