JSON Schema prüft nur tatsächlich formulierte Regeln
Lesbares JSON muss noch nicht für eine Anfrage geeignet sein. Ein Schema beschreibt erwartete Daten, erzwingt aber keine fehlende Bedingung und beweist keine externen Tatsachen.
Anwesenheit und Typ getrennt festlegen
Ein Feld unter properties wird eingeschränkt, wenn es vorhanden ist; allein dadurch ist es nicht Pflicht. Für zwingende Anwesenheit required verwenden.
Die Zahl 3 und die Zeichenfolge "3" unterscheiden sich. Akzeptanz bedeutet keine automatische Umwandlung des anderen Typs. Den Vertrag nach dem Bedarf des Empfängers entwerfen.
Quellen: JSON Schema — Properties, required fields and additional properties
Über zusätzliche Felder entscheiden
In einem einfachen Objektschema weist additionalProperties: false nicht deklarierte Felder zurück. Das findet etwa Schreibfehler, verlangt aber bewusste Anpassung bei Vertragserweiterungen.
Ein fehlendes Feld, einen falschen Typ und eine zusätzliche Eigenschaft testen. Mit einer gezielten Regel pro Beispiel wird das Ergebnis verständlich.
Quellen: JSON Schema — Properties, required fields and additional properties
Schemaerfolg genehmigt keine Anfrage
ToolRoof prüft lokal eine Teilmenge von Draft 2020-12. Keine entfernten Schemas oder vollständige Schlüsselwortunterstützung; nicht unterstützte Merkmale werden gemeldet statt still als gültig behandelt.
Ein Erfolg bestätigt weder Produktbestand noch Datenbankpreis oder Benutzerberechtigung. Auch default ergänzt in diesem Prüfer keine fehlenden Eingabefelder.
Beispiel: Pflichtmenge ohne verdeckte Typumwandlung
quantity soll integer mit Minimum 1 sein, in required stehen und Zusatzfelder sollen verboten sein. {"quantity":3} besteht; {"quantity":"3"} scheitert am Typ.
{} scheitert am fehlenden Feld; {"quantity":3,"note":"draft"} an der Zusatzangabe. Die akzeptierte 3 beweist keinen Lagerbestand von 3 Stück; das gehört nicht zu diesen Regeln.