Validierungsfehler ins Formular bringen

Worum es geht

Schickt ein Formular Daten, die gegen Feldregeln verstoßen, antwortet CDMS mit 422 und einer Liste violations. Jeder Eintrag nennt das Feld mit seinem Pfad und die verletzte Regel. Deine Aufgabe im Client: Jeden Eintrag dem passenden Eingabefeld zuordnen und dort eine verständliche Meldung zeigen.

Von der 422 zum markierten Formular

{
  "messageKey": "validation-failed",
  "code": "422",
  "violations": [
    { "field": "name",
      "rule": "cannot-be-empty" },
    { "field": "address.zip",
      "rule": "pattern-mismatch" },
    { "field": "contacts[1].email",
      "rule": "cannot-be-null" }
  ],
  …
}

Kunde anlegen
─────────────────────────────────────────
Name      [                 ]
          ⚠ darf nicht leer sein
Adresse
  Straße  [ Hauptstraße 1   ]
  PLZ     [ 123             ]
          ⚠ hat nicht das erlaubte Format
Ansprechpartner
  1  Anna   [ anna@muster.de ]
  2  Ben    [                ]
          ⚠ ist ein Pflichtfeld
─────────────────────────────────────────
Bitte die markierten Felder korrigieren.

Der Ablauf

Den Pfad lesen

Der Pfad in field beschreibt, wo das Feld im Objekt steckt, das du geschickt hast. Er beginnt innerhalb von data:

Am einfachsten wird es, wenn deine Formularfelder denselben Pfad als Namen tragen, also etwa name="contacts[1].email". Dann ist field direkt der Schlüssel, unter dem du die Meldung ablegst.

Der Index in […] ist die Position in der Liste, so wie du sie geschickt hast. Zeigt das Formular die Zeilen in derselben Reihenfolge, trifft die Meldung die richtige Zeile.

Die Regeln in Text übersetzen

Die Grenzen selbst, etwa die erlaubte Länge oder den Mindestwert, nennt die Antwort nicht. Willst du sie im Text zeigen, nimm sie aus deinem Modell. Welche Regel was prüft, steht unter Validierung.

Ein Beispiel in TypeScript

type Violation = { field: string; rule: string };

const TEXT: Record<string, string> = {
  'cannot-be-null':   'ist ein Pflichtfeld',
  'cannot-be-empty':  'darf nicht leer sein',
  'too-long':         'ist zu lang',
  'pattern-mismatch': 'hat nicht das erlaubte Format',
  'min-number':       'ist kleiner als erlaubt',
  'max-number':       'ist größer als erlaubt',
  'not-in-future':    'muss in der Zukunft liegen',
  'not-in-past':      'muss in der Vergangenheit liegen',
};

function byField(violations: Violation[]) {
  const errors: Record<string, string[]> = {};
  for (const v of violations) {
    const text = TEXT[v.rule] ?? `ist ungültig (${v.rule})`;
    (errors[v.field] ??= []).push(text);
  }
  return errors;
}

const res = await fetch(url, { method: 'POST', … });
if (res.status === 422) {
  const body = await res.json();
  const errors = byField(body.violations ?? []);
  for (const [path, texts] of Object.entries(errors)) {
    const input = form.querySelector(`[name="${path}"]`);
    if (input) markField(input, texts);
    else showFormMessage(`${path} ${texts.join(', ')}`);
  }
}

Zwei Dinge macht das Beispiel bewusst:

• Eine unbekannte Regel bekommt einen allgemeinen Text statt eines Absturzes. So bleibt dein Client stabil, wenn eine Regel dazukommt.
• Ein Feld, das das Formular nicht zeigt, landet in der Meldung über dem Formular. Das passiert etwa bei einem PUT, wenn ein Pflichtfeld nicht im Formular steht und deshalb als null ankommt.

Alle Ausprägungen

Andere Fehler mit Feldbezug

Nicht nur 422 kann ein Feld betreffen. Auch ein Wert, der gar nicht zum Feldtyp passt, etwa Text in einem Zahlfeld, wird abgelehnt: mit 400 invalid-value|<pfad>. Das kommt vor der Prüfung der Regeln, also allein und ohne violations.

Der Pfad steht hier im messageKey hinter dem |. Bei Create und PUT beginnt er an der Wurzel des Körpers (data.amount), bei PATCH innerhalb von data (amount). Schneide ein führendes data. ab, dann passt er zu deinen Formularfeldern.

Fallen

Wie es weitergeht

• Welche Regeln es gibt und wann sie gelten: Validierung
• Warum PUT andere Felder meldet als PATCH: PUT oder PATCH? Die null-Falle
• Der Aufbau jeder Fehlerantwort: Das Fehlerformat