JSON Toolkit

Was JSON Schema tatsächlich löst

Fazit: Schema regelt Struktur und Typen, nicht Geschäftsbedeutung. Es verhindert fehlende Felder, falsche Typen und Enums außerhalb des Bereichs, während Regeln wie Betrag über null im Code bleiben.

Fortgeschritten~4 Min. LesezeitVeröffentlicht 2026-10-30Aktualisiert 2026-10-30
Die Grenze dessen, was JSON Schema erzwingen kann

Kurz gesagt: Lassen Sie JSON Schema Struktur, Typen, Bereiche und Formate erzwingen, während feldübergreifende Regeln, Geschäftsinvarianten und externer Zustand im Code bleiben; übernehmen Sie es für öffentliche APIs und geteilte Payloads, nicht für einen internen Dienst mit fünf Feldern.

Es beantwortet „ist diese Datenform korrekt“, nicht „ergibt diese Daten Sinn“.

Was es gut kann

Strukturelle Vollständigkeit. Welche Felder existieren müssen, ob zusätzliche erlaubt sind (required, additionalProperties).

Typen. port als Zahl oder String, tags als Array oder Skalar. Allein das entfernt viel defensiven Code in mehrsprachigen Systemen.

Bereiche. enum, minimum/maximum, String- und Array-Länge.

Formate. format für Daten, E-Mail, URIs und UUIDs, mit Validatoren, die sie erzwingen.

Verschachtelung. Jede Ebene von Objekten und Arrays bekommt eigene Beschränkungen, und Fehler tragen einen präzisen Pfad.

Dokumentation. Das Schema ist der Vertrag. Ändern Sie ein Feld, und der Diff zeigt den Wirkungsradius. Es generiert auch Typen und Formulare, eine Definition speist also mehrere Konsumenten.

Was es nicht kann

Feldübergreifende Abhängigkeiten. „Ende muss nach Start liegen“ lässt sich mit if/then/else ausdrücken, aber das Ergebnis ist länger und schwerer zu lesen als drei Zeilen Code.

Geschäftsinvarianten. „Bestand darf nicht negativ werden“ hängt von externem Zustand ab. Schema sieht ein Dokument.

Semantik. price: -100 erfüllt {"type": "number"} perfekt. Ob es ein legaler Preis ist, liegt außerhalb des Wissens des Schemas.

Eine praktikable Aufteilung

Schicht Besitzer
Syntax: ist es gültiges JSON Parser
Struktur: Felder, Typen, Bereiche, Formate JSON Schema
Semantik: feldübergreifend, Geschäftsregeln, externer Zustand Anwendungscode
Sicherheit: Größe, Tiefe, Rate Gateway / Middleware

Falten Sie diese in eine Stelle, und das Schema wächst auf Hunderte Zeilen mit fünf Ebenen if/then. Dann umgehen die Leute es.

Wann es sich lohnt

  • Öffentliche APIs mit unbekannten Konsumenten
  • Mehrere Dienste, die dieselbe Payload lesen
  • Konfigurationsgetriebene Systeme, in denen Tippfehler schnell scheitern müssen
  • Typen oder Formulare aus dem Vertrag generieren

Für einen kleinen internen Dienst mit fünf Feldern und einem Frontend sind handgeschriebene Prüfungen schneller zu pflegen. Schema dort einzuführen ist negative Arbeit.

FAQ

Wie entscheide ich, ob ich JSON Schema übernehme?

Wägen Sie öffentliche Konsumenten, mehrere Dienste, die dieselbe Payload lesen, und das Bedürfnis, Typen oder Formulare zu generieren. Für einen kleinen internen Dienst mit fünf Feldern und einem Frontend sind handgeschriebene Prüfungen schneller zu pflegen.

Warum sollten feldübergreifende Regeln im Code bleiben?

„Ende muss nach Start liegen“ lässt sich in if/then/else quetschen, aber das Ergebnis ist länger und schwerer zu lesen als ein paar Zeilen Code. Schema kann auch externen Zustand nicht sehen.

Sollte Schema Payload-Größe und Verschachtelungstiefe validieren?

Nein. Schema beschreibt Struktur, nicht Größe oder Tiefe; diese Limits gehören in ein Gateway oder eine Middleware-Schicht.

Weiterführende Literatur