JSON Schema असल में क्या हल करता है
मुख्य बात: Schema संरचना और टाइप नियंत्रित करता है, व्यावसायिक अर्थ नहीं। यह गायब फ़ील्ड, गलत टाइप और सीमा से बाहर enums रोकता है, जबकि शून्य से अधिक राशि जैसे नियम code में ही रहते हैं।
मुख्य बात: JSON Schema को संरचना, टाइप, सीमाएँ और फ़ॉर्मैट लागू करने दें, जबकि cross-field नियम, व्यावसायिक invariants और बाहरी state code में रहें; इसे सार्वजनिक APIs और साझा payloads के लिए अपनाएँ, पाँच फ़ील्ड वाली आंतरिक सेवा के लिए नहीं।
यह जवाब देता है "क्या यह डेटा सही आकार में है", यह नहीं कि "क्या इस डेटा का कोई अर्थ है"।
यह क्या अच्छी तरह करता है
संरचनात्मक पूर्णता। कौन से फ़ील्ड मौजूद होने चाहिए, अतिरिक्त फ़ील्ड की अनुमति है या नहीं (required, additionalProperties)।
टाइप। port number है या string, tags array है या scalar। अकेले यह बहुभाषी सिस्टम में बहुत सारा defensive code हटा देता है।
सीमाएँ। enum, minimum/maximum, string और array की लंबाई।
फ़ॉर्मैट। dates, email, URIs और UUIDs के लिए format, साथ में उन्हें लागू करने वाले validators।
Nesting। objects और arrays का हर स्तर अपने स्वयं के constraints रखता है, और errors एक सटीक path लेकर आते हैं।
प्रलेखन। Schema ही अनुबंध है। फ़ील्ड बदलें और diff दिखा देता है कि असर कहाँ-कहाँ पड़ेगा। यह टाइप और forms भी बनाता है, इसलिए एक परिभाषा कई उपभोक्ताओं को सेवा देती है।
यह क्या नहीं कर सकता
Cross-field निर्भरताएँ। "समाप्ति शुरू के बाद होनी चाहिए" को if/then/else से बताया जा सकता है, पर परिणाम कोड की तीन पंक्तियों से लंबा और पढ़ने में कठिन होता है।
व्यावसायिक invariants। "स्टॉक ऋणात्मक नहीं जा सकता" बाहरी state पर निर्भर है। Schema केवल एक document देखता है।
Semantics। price: -100 {"type": "number"} को पूरी तरह संतुष्ट करता है। क्या यह वैध मूल्य है, यह Schema के ज्ञान से बाहर है।
काम करने योग्य विभाजन
| स्तर | स्वामी |
|---|---|
| सिंटैक्स: क्या यह वैध JSON है | Parser |
| संरचना: फ़ील्ड, टाइप, सीमाएँ, फ़ॉर्मैट | JSON Schema |
| Semantics: cross-field, व्यावसायिक नियम, बाहरी state | Application code |
| सुरक्षा: आकार, गहराई, दर | Gateway / middleware |
इन सबको एक जगह ठूँस दें तो Schema सैकड़ों पंक्तियों का हो जाता है जिसमें if/then के पाँच स्तर होते हैं। उस बिंदु पर लोग उससे बचकर निकलने लगते हैं।
यह कब फ़ायदेमंद है
- अपरिचित उपभोक्ताओं वाले सार्वजनिक APIs
- एक ही payload पढ़ने वाली कई सेवाएँ
- कॉन्फ़िग-चालित सिस्टम जहाँ typos को तुरंत विफल होना चाहिए
- अनुबंध से टाइप या forms बनाना
पाँच फ़ील्ड और एक frontend वाली छोटी आंतरिक सेवा के लिए हाथ से लिखे जाँच बनाए रखने में तेज़ होते हैं। वहाँ Schema जोड़ना नकारात्मक काम है।
FAQ
JSON Schema अपनाना है या नहीं, यह कैसे तय करूँ?
सार्वजनिक उपभोक्ताओं, एक ही payload पढ़ने वाली कई सेवाओं, और टाइप या forms बनाने की ज़रूरत को तौलें। पाँच फ़ील्ड और एक frontend वाली छोटी आंतरिक सेवा के लिए हाथ से लिखे जाँच बनाए रखने में तेज़ होते हैं।
Cross-field नियम code में क्यों रहने चाहिए?
"समाप्ति शुरू के बाद होनी चाहिए" को if/then/else में ठूँसा जा सकता है, पर परिणाम कोड की कुछ पंक्तियों से लंबा और पढ़ने में कठिन होता है। Schema बाहरी state भी नहीं देख सकता।
क्या Schema को payload का आकार और nesting गहराई validate करनी चाहिए?
नहीं। Schema संरचना बताता है, आकार या गहराई नहीं; वे सीमाएँ gateway या middleware परत की हैं।