Vom Beispiel aus
Objekte, Arrays, Strings, Zahlen werden auf den jeweiligen type abgebildet. Nested Objekte möglichst als properties.
Leere Arrays ohne Elementbeispiel: items-Typ oft ungenau – ein echtes Element ergänzen und neu ableiten.
Daten auch über #data={"name":"Ada"} oder #url=... einfügen; nach dem Lesen wird die Adressleiste geleert.
JSON Schema aus einem Beispiel-JSON ableiten. Gut, wenn echte Antworten zuerst da sind und Doku oder Validatoren folgen. Pflichtfelder und Enums von Hand prüfen – das Tool sieht nur «was in diesem Beispiel steckt», nicht «was fachlich Pflicht ist».
Objekte, Arrays, Strings, Zahlen werden auf den jeweiligen type abgebildet. Nested Objekte möglichst als properties.
Leere Arrays ohne Elementbeispiel: items-Typ oft ungenau – ein echtes Element ergänzen und neu ableiten.
Automatik weiß nicht, ob ein Feld Pflicht ist – required anpassen. Optionale Felder, Enums, format (email, uri) von Hand ergänzen.
Danach mit ajv & Co. in CI laufen lassen – stabiler als mündliche Absprachen.
Beispieldaten werden nicht hochgeladen. Produktionsbeispiele trotzdem zuerst maskieren.
Die Ausgabe enthält $schema -Deklarationen, damit andere Tools die Version erkennen.
{
"id": 1001,
"name": "Ada",
"active": true
}
{
"type": "object",
"properties": {
"id": { "type": "number" },
"name": { "type": "string" },
"active": { "type": "boolean" }
}
}
Diese Seite erzeugt Schema aus Beispielen. Das Ergebnis an Backend oder CI (ajv etc.) zur Validierung geben.
Es wird möglichst tiefer abgeleitet. Leere Arrays ohne Elementbeispiel: item-Typ oft ungenau.
REST / JSON-Doku mit Schema; GraphQL-Dienste mit der Typableitungsseite.
Schwerpunkt Typableitung. E-Mail-Formate fachlich ins Schema nachtragen.
Ein Beispiel ergibt keinen vollständigen Vertrag. Mehrere Samples kreuzen, dann das Schema straffen.