Das Format von Validierungsfehlern verstehen

Kapitel 19 zeigte das violations-Array – dieses Kapitel geht ins Detail, WARUM dieses Format so aussieht und WIE React (Block 9) es sinnvoll auswertet.

Zwei Ebenen: hydra:description und violations

Die Antwort enthält die Fehler ZWEIMAL, in ZWEI unterschiedlichen Formen: hydra:description als EIN zusammengefasster, für Menschen lesbarer String (alle Meldungen mit Zeilenumbruch getrennt), UND violations als STRUKTURIERTES Array – jeder Eintrag EINEM konkreten Feld zugeordnet über propertyPath.

Achtung: Für ein Frontend ist violations die RICHTIGE Wahl: hydra:description lässt sich NICHT zuverlässig einem einzelnen Formularfeld zuordnen, propertyPath dagegen SCHON.

Mehrere Fehler auf verschiedenen Feldern

curl -k -X POST https://localhost/api/projects \
  -H 'Content-Type: application/json' \
  -d '{"name": "ab"}'

{
  "violations": [
    {"propertyPath": "name", "message": "This value is too short. It should have 3 characters or more."}
  ]
}

propertyPath entspricht EXAKT dem Property-Namen der Entity (name) – bei VERSCHACHTELTEN Objekten (Block 5) wird daraus ein PFADAUSDRUCK wie tags[0].name.

Abgrenzung zum Parser-Fehler aus Kapitel 16

Statuscode	Ursache
`400 Bad Request`	JSON ist syntaktisch KAPUTT, der Parser scheitert VOR jeder Entity-Zuordnung
`422 Unprocessable Entity`	JSON ist syntaktisch KORREKT, aber ein Constraint schlägt fehl (semantischer Fehler)

Ein Frontend MUSS beide Fälle UNTERSCHIEDLICH behandeln: 400 ist ein PROGRAMMIERFEHLER im Client (sollte NIE bei korrekt geschriebenem Code auftreten), 422 ist ein NORMALER, vom NUTZER verursachter Fall, der im UI AUFGEFANGEN werden muss.

Tipp: React Hook Form (Block 9) lässt sich DIREKT mit dem violations-Array füttern – setError(propertyPath, { message }) pro Eintrag reicht bereits aus, um Feld-für-Feld-Fehleranzeigen zu erzeugen.