Alcune domande relative allo schema json personalizzato

Question

Sono un noob in giapponese. Durante la definizione del formato del risultato del mio RESTful API (JSON), ho pensato che sarebbe stato più semplice documentarlo come il mio JSON schema. Durante la scrittura di uno ho avuto alcune domande:

1. Nel mio risultato JSON, come si specifica l'URI allo schema a cui conferma? --edit-- sta usando l'attributo $schema?
2. Esistono convenzioni/linee guida per il controllo delle versioni dello schema JSON? Ci sono alcuni attributi che dovrei/posso definire all'interno del mio schema come attributi? Vedo che JSON schema itself non ha alcuna versione definita tranne nel suo URI specificato come valore della chiave $schema.
3. Posso analizzare il mio schema BIG JSON in più di uno più piccolo e includerne uno in un altro? Come #include in C++, quindi fai riferimento a più schemi nel JSON che ho inviato all'utente come risultato.
4. Posso definire un valore personalizzato per il tasto "tipo"? Per esempio. Vorrei riutilizzare la definizione di "data" come questo:

[ignorare questa linea, è di ottenere la formattazione di lavoro per seguire JSON ..]

{ 
    "date":{ 
     "type":"object", 
     "properties":{ 
      "month":{ 
       "type":"integer", 
       "minimum":1, 
       "maximum":12 
      }, 
      "year":{ 
       "type":"integer", 
       "minimum":0 
      } 
     } 
    }, 
    "personInfo":{ 
     "type":"object", 
     "properties":{ 
      "name":{ 
       "type":"string" 
      }, 
      "dateOfBirth":{ 
       "type":"date" 
      } 
     } 
    }, 
    "student":{ 
     "type":"object", 
     "properties":{ 
      "id":{ 
       "type":"personInfo" 
      }, 
      "pass_out_year":{ 
       "type":"date" 
      } 
     } 
    } 
} 

invece di fornire proprietà della " data" in luoghi multipli come questo:

{ 
    "personInfo":{ 
     "type":"object", 
     "properties":{ 
      "name":{ 
       "type":"string" 
      }, 
      "dateOfBirth":{ 
       "type":"object", 
       "properties":{ 
        "month":{ 
         "type":"integer", 
         "minimum":1, 
         "maximum":12 
        }, 
        "year":{ 
         "type":"integer", 
         "minimum":0 
        } 
       } 
      } 
     } 
    }, 
    "student":{ 
     "type":"object", 
     "properties":{ 
      "id":{ 
       "type":"personInfo" 
      }, 
      "pass_out_year":{ 
       "type":"object", 
       "properties":{ 
        "month":{ 
         "type":"integer", 
         "minimum":1, 
         "maximum":12 
        }, 
        "year":{ 
         "type":"integer", 
         "minimum":0 
        } 
       } 
      } 
     } 
    } 
} 

in base al tipo 5.1 in the spec, non è possibile, ma sembra un caso d'uso come base!

Answer 1

1. Come è stato calcolato correttamente, è possibile utilizzare $schema per specificare lo schema a cui è conforme.
2. In realtà ho trovato questo argomento mentre cercavo su google per la versione di JSON Schema e l'idea di utilizzare l'URI per il controllo delle versioni sembra logica.
3. È possibile utilizzare $ref per collegarsi a un altro schema che viene quindi inserito.
4. Ancora, è possibile utilizzare $ref e JSON Pointer per importare le definizioni da altri schemi.

Puoi sempre verificare le cose con lo validating schema per vedere se hai commesso degli errori.

Answer 2

Le specifiche sembra suggerire che si potrebbe:

Altri valori tipo potrebbero essere utilizzati per scopi personalizzati, ...

Si passa poi a discutere di ciò che validatori del minimo implementazione potrebbe fare.

A mio parere, quello che vuoi fare sembra OK. Potrebbe aiutare la chiarezza dello schema a mantenere il riferimento del tipo e la definizione del tipo nello stesso file.

Penso che il tuo file includa Q dovrebbe essere gestito al di fuori di JSON, ad es. avere un passo dev che genera il json completo da uno script/modello (ad es. erb o altri) unendo i subfile. A mio avviso, il tuo servizio dovrebbe sempre consegnare l'intero json necessario per interagire pienamente con quel servizio. Se questo diventa ingestibile dal punto di vista dei clienti, potrebbe essere un segnale per refactoring e introdurre un altro servizio.

Answer 3

Perché non usi semplicemente lo "format" : "date" come da #5.23 in JSON Schema Draft 03?

Inoltre, la definizione di data di nascita non contiene la data che sembra essere un errore.

Answer 4

Al momento in cui scriviamo, la versione corrente delle specifiche JSON schema è progetto-v4, in cui il formato date-time per string casi è clearly specified ed è molto utile nella pratica.

non esiste un formato più semplice date definito fino ad ora, ma si può facilmente definire la proprietà del proprio oggetto come tipo string e quindi applicare una formatpattern validation (ECMA 262 dialetto regex) su di esso.

Ad esempio:

{ 
    "$schema": "http://json-schema.org/draft-04/schema", 
    "title": "Example Schema" 
    "description": "This schema contains only a birth date property" 
    "type": "object", 
    "required": ["birth_date"], 
    "properties": { 
     "birth_date": { 
      "type": "string", 
      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$" 
     } 
    } 
}