Perché il mio schema generato rifiuta dati validi?

Quasi sempre perché ogni chiave è stata contrassegnata come obbligatoria, oppure perché un campo che nel campione era null è stato tipizzato come null anziché come nullable. Entrambi sono artefatti dell'inferenza da un solo documento ed entrambi vanno corretti a mano.

Come ottengo uno schema davvero utile?

Considera l'output una prima bozza. Allarga a unioni i campi che ammettono null, togli da required le chiavi realmente facoltative, aggiungi format ed enum dove conosci il vincolo, e validalo su più documenti reali anziché su quello da cui l'hai generato.

Generatore schemi JSON

Incolla JSON e genera un JSON Schema.

JSON di input

Tutti i calcoli sono eseguiti localmente nel tuo browser. Nessun dato viene inviato al server.

I risultati hanno carattere informativo. Verificali con altre fonti.

Inferire uno JSON Schema, e ciò che l'inferenza non può sapere

Uno schema generato da un campione descrive quel campione, non il tuo modello di dati. Azzecca la forma e sbaglia l'intenzione, perché un singolo esempio non può dire quali campi siano facoltativi, quali valori formino un'enumerazione e quali null abbiano significato.

Come funziona

Percorre il JSON ed emette un tipo per ogni valore: oggetto, array, stringa, numero, booleano o null.
Contrassegna come obbligatoria ogni chiave presente nel campione, perché è tutto ciò che un singolo esempio può sostenere.
Scende ricorsivamente negli oggetti annidati e deduce i tipi degli elementi degli array da ciò che trova.

tipi dedotti
  "testo"     → string
  42          → number (integer se senza decimali)
  true        → boolean
  null        → null   (non "facoltativo")
  [ ... ]     → array con elementi dedotti
  { ... }     → object con proprietà

required = ogni chiave vista nel campione

Esempio pratico

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

id → integer, name → string
email → null, quasi certamente sbagliato: dovrebbe essere ["string", "null"]
tags → array di stringhe
tutte e quattro le chiavi contrassegnate come obbligatorie
nessun maxLength, nessun format, nessun enum: nulla di ciò è visibile in un campione

Uno schema strutturalmente corretto che rifiuterebbe dati validi. Il campo email tipizzato come null accetta solo null, e contrassegnare tutte le chiavi come obbligatorie rifiuta qualunque record in cui una manchi.

Come leggere il risultato

Un null nel campione non significa che il tipo sia null. Quasi sempre significa che il campo ammette null, quindi il tipo corretto è un'unione come ["string", "null"]. L'inferenza non sa distinguerli e indovina sempre il più stretto.
Finisce tutto in required perché l'assenza è invisibile. Fornisci più documenti differenti e l'unione delle chiavi mostrerà la forma vera; con un solo campione stai descrivendo quel documento.
Formati, enumerazioni e limiti sono invisibili all'inferenza. Un'e-mail, un UUID, una data e una stringa qualsiasi appaiono identici; aggiungere format, enum, minimum e maxLength è il lavoro che trasforma una forma in un contratto.
Gli array sono l'inferenza più debole. Un array vuoto non dà alcun tipo di elemento, e un array di tipi misti di solito significa che il campione non è rappresentativo, non che il campo accetti davvero qualsiasi cosa.

Domande frequenti

Perché il mio schema generato rifiuta dati validi?: Quasi sempre perché ogni chiave è stata contrassegnata come obbligatoria, oppure perché un campo che nel campione era null è stato tipizzato come null anziché come nullable. Entrambi sono artefatti dell'inferenza da un solo documento ed entrambi vanno corretti a mano.
Come ottengo uno schema davvero utile?: Considera l'output una prima bozza. Allarga a unioni i campi che ammettono null, togli da required le chiavi realmente facoltative, aggiungi format ed enum dove conosci il vincolo, e validalo su più documenti reali anziché su quello da cui l'hai generato.

Fonti

JSON Schema Specification