draft-07 या 2020-12
मुख्य बात: 2020-12 वर्तमान है और `$defs`, `prefixItems` तथा `unevaluatedProperties` जोड़ता है, पर कई टूल अब भी केवल draft-07 बोलते हैं। अपनी पूरी toolchain क्या समर्थन करती है, उससे चुनें।
मुख्य बात: नए प्रोजेक्ट्स के लिए 2020-12 उपयोग करें, जिस पल कोई validator, code generator या OpenAPI टूल केवल draft-07 समर्थन करे तभी draft-07 पर लौटें, और हमेशा $schema से draft पिन करें।
संक्षेप में: नए काम के लिए 2020-12, जब कोई पुराना घटक मजबूर करे तब draft-07।
समयरेखा
| Draft | वर्ष | उल्लेखनीय |
|---|---|---|
| draft-04 | 2013 | $id के बजाय id; पुराने APIs में अब भी आम |
| draft-06 | 2017 | const, propertyNames |
| draft-07 | 2018 | if/then/else, readOnly, contentMediaType; सर्वोत्तम संगतता |
| 2019-09 | 2019 | definitions की जगह $defs, unevaluatedProperties |
| 2020-12 | 2020 | prefixItems, $dynamicRef; वर्तमान सिफ़ारिश |
2020-12 क्या सुधारता है
Array tuples विशेष मामला रहना बंद करते हैं। draft-07 "पहला element A है, दूसरा B" को items: [{...}, {...}] और additionalItems से बताता है। 2020-12 स्थान-विशिष्ट schemas के लिए prefixItems और बाकी के लिए items उपयोग करता है।
$defs मानक नाम है। 2019 के बाद लिखा गया tooling डिफ़ॉल्ट रूप से वहीं देखता है।
unevaluatedProperties composition के साथ काम करता है। allOf के साथ additionalProperties: false साथी शाखाओं द्वारा परिभाषित फ़ील्ड को अस्वीकार कर देता है। unevaluatedProperties: false केवल उन properties को गिनता है जिन्हें पूरा schema वास्तव में evaluate करता है, और composition को यही चाहिए।
draft-07 कब सही जवाब है
| स्थिति | कारण |
|---|---|
| OpenAPI 3.0 | इसका schema object draft-04/07 का उपसमुच्चय है |
| पुराने validators (ajv 6, कुछ Java लाइब्रेरी) | वे prefixItems या $dynamicRef नहीं जानते |
| प्लेटफ़ॉर्म संस्करण अनिवार्य करे | कुछ low-code प्लेटफ़ॉर्म और gateways इसे पिन करते हैं |
| 07 पर रुकने वाले code generators | अपरिचित keywords चुपचाप अनदेखा किए जाते हैं |
आख़िरी स्थिति सीधे जाँचें: prefixItems वाला schema अपने validator को दें। अगर यह अपरिचित keyword की शिकायत के बजाय बिना किसी शिकायत के pass हो जाए, तो यह constraint को अनदेखा कर रहा है — जो सबसे ख़तरनाक परिणाम है।
संस्करण मिलाना
हमेशा $schema घोषित करें। डिफ़ॉल्ट अलग होते हैं: ajv draft-07 मान लेता है, कई Python लाइब्रेरी 2020-12 मान लेती हैं। तब वही फ़ाइल दो जगह अलग-अलग validate होती है।
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://example.com/schemas/order.json",
"type": "object"
}
drafts के पार $ref न करें। व्यवहार अपरिभाषित है।
बैचों में अपग्रेड करें। एक रिपॉज़िटरी में दो drafts "यहाँ कौन से नियम लागू हैं" को मौखिक ज्ञान बना देते हैं।
FAQ
मेरा validator 2020-12 समर्थन करता है या नहीं, कैसे जाँचूँ?
prefixItems उपयोग करने वाला schema validator को दें। unknown-keyword error का मतलब है कि यह draft समर्थन नहीं करता; चुपचाप pass होने का मतलब है कि यह constraint को अनदेखा कर रहा है, जो अधिक बुरा है।
एक प्रोजेक्ट में एक ही draft क्यों उपयोग करना चाहिए?
एक रिपॉज़िटरी में दो drafts "यहाँ कौन से नियम लागू हैं" को मौखिक ज्ञान बना देते हैं। बैचों में अपग्रेड करें ताकि हर फ़ाइल की व्याख्या एक जैसी रहे।
क्या हमेशा $schema घोषित करना चाहिए?
हाँ। डिफ़ॉल्ट अलग होते हैं: ajv draft-07 मान लेता है जबकि कई Python लाइब्रेरी 2020-12 मान लेती हैं, इसलिए वही फ़ाइल दो जगह अलग-अलग validate हो सकती है।