Skip to main content

JSON-Schema-Generator

Deutsch

Fügen Sie JSON ein und erzeugen Sie ein JSON Schema.

Alle Berechnungen erfolgen lokal in Ihrem Browser. Es werden keine Daten an einen Server gesendet.

Die Ergebnisse dienen zur Information. Überprüfen Sie sie anhand anderer Quellen.

Ein JSON-Schema ableiten — und was Ableitung nicht wissen kann

Ein aus einem Beispiel erzeugtes Schema beschreibt dieses Beispiel, nicht Ihr Datenmodell. Es trifft die Form und verfehlt die Absicht, denn ein einzelnes Dokument kann nicht sagen, welche Felder optional sind, welche Werte Aufzählungen bilden und welche Nullwerte Bedeutung tragen.

So wird gerechnet

  • Durchläuft das JSON und gibt für jeden Wert einen Typ aus: Objekt, Array, String, Zahl, Boolean oder Null.
  • Markiert jeden im Beispiel vorhandenen Schlüssel als erforderlich, denn mehr trägt ein einzelnes Beispiel nicht.
  • Steigt rekursiv in verschachtelte Objekte ab und leitet Array-Elementtypen aus den gefundenen Elementen ab.
abgeleitete Typen
  "text"      → string
  42          → number (integer ohne Nachkommastellen)
  true        → boolean
  null        → null   (nicht "optional")
  [ ... ]     → array mit abgeleiteten Elementen
  { ... }     → object mit Eigenschaften

required = jeder im Beispiel gesehene Schlüssel

Rechenbeispiel

Ableitung aus {"id": 1, "name": "Ada", "email": null, "tags": ["a", "b"]}.

  1. id → integer, name → string
  2. email → null, was fast sicher falsch ist: gemeint ist ["string", "null"]
  3. tags → Array aus String
  4. alle vier Schlüssel als erforderlich markiert
  5. kein maxLength, kein format, kein enum — nichts davon ist in einem Beispiel sichtbar

Ein strukturell korrektes Schema, das gültige Daten ablehnen würde. Das als null typisierte E-Mail-Feld akzeptiert nur null, und alle Schlüssel als erforderlich zu markieren weist jeden Datensatz ab, in dem einer fehlt.

Das Ergebnis lesen

  • Ein null im Beispiel heißt nicht, dass der Typ null ist. Fast immer heißt es, das Feld ist nullable, der richtige Typ also eine Union wie ["string", "null"]. Ableitung kann das nicht unterscheiden und rät stets die engere Variante.
  • Alles landet in required, weil Abwesenheit unsichtbar ist. Füttern Sie mehrere abweichende Dokumente, dann zeigt die Vereinigung der Schlüssel die wahre Form — mit einem Beispiel beschreiben Sie nur dieses Dokument.
  • Formate, Aufzählungen und Grenzen sind für die Ableitung unsichtbar. Eine E-Mail, eine UUID, ein Datum und ein beliebiger String sehen identisch aus; format, enum, minimum und maxLength zu ergänzen ist die Arbeit, die aus einer Form einen Vertrag macht.
  • Arrays sind die schwächste Ableitung. Ein leeres Array liefert gar keinen Elementtyp, und ein Array gemischter Typen bedeutet meist, dass das Beispiel unrepräsentativ ist, nicht dass das Feld wirklich alles akzeptiert.

Häufige Fragen

Warum weist mein erzeugtes Schema gültige Daten ab?
Fast immer, weil jeder Schlüssel als erforderlich markiert wurde oder weil ein im Beispiel leeres Feld als null statt als nullable typisiert ist. Beides sind Artefakte der Ableitung aus einem Dokument und beides muss von Hand korrigiert werden.
Wie bekomme ich ein wirklich brauchbares Schema?
Behandeln Sie die Ausgabe als ersten Entwurf. Erweitern Sie nullable Felder zu Unions, nehmen Sie echte Optionalfelder aus required heraus, ergänzen Sie format und enum, wo Sie die Einschränkung kennen, und prüfen Sie gegen mehrere echte Dokumente statt gegen das eine, aus dem Sie es erzeugt haben.

Quellen