JSON Schema Validator

Paano i-validate ang JSON laban sa schema

1. I-paste ang iyong schema sa JSON Schema at ang iyong data sa JSON document, o pumili ng handang kaso mula sa Halimbawa.
2. Iwanan ang Draft sa Awtomatiko ($schema) para gamitin ang bersyong pinangalanan ng $schema ng schema, o piliting gamitin ang draft 4, 7, 2019-09 o 2020-12.
3. Tumatakbo ang validation habang nagta-type ka; muling pinapatakbo ito ng I-validate. Ang I-format ang dalawa ay nagre-re-indent sa dalawang text.
4. Basahin ang resulta: berdeng linya kapag valid ang document, kung hindi ay talahanayan ng mga error. Nasa Ingles ang mga mensahe ng error mula sa validator.

Pagbasa ng talahanayan ng error

Ang bawat hilera ay isang pumalyang tuntunin:

• Ang Instance path ay JSON Pointer sa value na pumalya. Ang /roles/1 ay ang pangalawang item ng roles; ang (root) ay ang buong document.
• Ang Keyword ay ang tuntunin ng schema na pumalya: type, required, minimum, pattern, format, additionalProperties at iba pa.
• Ipinapaliwanag ng Mensahe ang pagpalya, halimbawa 0 is less than 1.
• Tumuturo ang Schema path sa keyword sa loob ng schema, gaya ng /properties/id/minimum, kaya mabilis mong mahahanap ang tuntunin.

Hindi humihinto ang validation sa unang problema: nakalista ang lahat ng error. Kapag pumalya ang property ng object, nag-uulat ang validator ng buod (“Property “id” does not match schema”) na sinusundan ng eksaktong dahilan. Itinatago ng Ipakita lang ang pinakatiyak na mga error ang mga buod na iyon; alisin ang check para makita ang buong hanay. Ang mga error sa ilalim ng anyOf at oneOf ay laging pinagsasama kasama ng mga tiyak na error ng bawat sanga, dahil may saysay lang ang mga ito nang magkakasama.

Ano ang suportado

• Mga draft: 4, 6 (vina-validate gamit ang mga tuntunin ng draft 7), 7, 2019-09 at 2020-12, kasama ang $defs/definitions, lokal na $ref, if/then/else, dependentRequired, dependentSchemas, prefixItems, unevaluatedProperties at unevaluatedItems.
• Mga format: tinitingnan ang date, time, date-time, duration, email, hostname, ipv4, ipv6, uri, uri-reference, uri-template, uuid, regex, json-pointer at relative-json-pointer. Binabalewala ang mga hindi kilalang format, gaya ng pinapayagan ng specification.
• Mga reference: ang $ref ay maaaring tumuro kahit saan sa loob ng schema, kasama ang $id na idineklara nito. Hindi kailanman dina-download ang mga remote schema; ang reference sa ibang URL ay iniuulat bilang hindi nalutas.

Ang tool na ito ay nagva-validate ng mga document laban sa iyong schema. Hindi nito sinusuri kung sumusunod ang schema mismo sa meta-schema, pero binabalaan ka nito tungkol sa mga hindi kilalang pangalan ng type gaya ng "strin" o "int", isang karaniwang typo na tahimik na binabalewala ng ibang validator.

Ang mga halimbawa

• Profile ng user (2020-12): required, haba ng string, format: email, enum sa loob ng items, uniqueItems at additionalProperties: false.
• Listahan ng produkto na may $ref (draft-07): array na ang mga item ay tumutukoy sa #/definitions/product, may pattern para sa SKU at presyong may exclusiveMinimum.
• Config na may if/then (2019-09): sertipikong kailangan lang sa HTTPS mode, oneOf sa pagitan ng email at URI, at mga limitasyong numeriko.

Bawat halimbawa ay may kasamang document na may sadyang mga pagkakamali, para makita mo kung ano ang itsura ng mga error.