JSON से JSON स्कीमा: नमूना पेलोड से अनुबंध तक

अनुमान क्या देख सकता है और क्या नहीं

एक एकल दस्तावेज़ से, एक अच्छा कनवर्टर प्रकार, नेस्टिंग, सरणी आइटम आकार और संपत्ति के नाम सटीक रूप से प्राप्त करता है। यह जो प्राप्त नहीं कर सकता वह इरादा है। यह नहीं जानता कि कोई फ़ील्ड वैकल्पिक है क्योंकि इस विशेष रिकॉर्ड में इसे शामिल किया गया है, कि एक स्ट्रिंग एक ईमेल पता है, कि एक संख्या एक सकारात्मक पूर्णांक है, या कि एक मान एक निश्चित सेट से आता है। इसलिए प्राप्त की गई हर चीज को `required` के रूप में चिह्नित किया जाता है, जो अनुबंध ड्राफ्ट के लिए सही डिफ़ॉल्ट है और बिना जांचे भेजे जाने वाली गलत चीज़ है।

उत्पन्न स्कीमा को सख्त बनाना

1. दो या तीन वास्तविक नमूनों की तुलना करें: जो कुंजियाँ किसी नमूने से गायब हैं उन्हें `required` से बाहर कर देना चाहिए।
2. जहाँ अर्थ ज्ञात हो वहाँ `format` जोड़ें - `date-time`, `email`, `uri`, `uuid`, `ipv4`।
3. जब फ़ील्ड में वास्तव में एक निश्चित शब्दावली हो, जैसे स्थिति या क्षेत्र, तो खुले सेट को `enum` मानों में बदलें।
4. संख्याओं को `minimum`, `maximum` और `multipleOf` से कसें ताकि कोई नकारात्मक मात्रा मान्य न हो सके।
5. `additionalProperties: false` केवल तभी जोड़ें जब अज्ञात कुंजियों को अस्वीकार किया जाना चाहिए - अन्यथा आगे की अनुकूलता के लिए स्कीमा को खुला छोड़ दें।

प्रतिज्ञा की आवश्यकता है, अवलोकन की नहीं। किसी फ़ील्ड को चिह्नित करना आवश्यक है क्योंकि आपके एक नमूने में वह शामिल है, यह सबसे आम तरीका है जिससे एक अनुमानित स्कीमा वास्तविक एकीकरण को तोड़ता है।

जहां स्कीमा अपनी कमाई अर्जित करती है

व्यावहारिक मूल्य सीमाओं पर दिखाई देता है: इस पर भरोसा करने से पहले एक वेबहुक पेलोड को मान्य करना, सीआई में फिक्स्चर फ़ाइलों की जांच करना ताकि परीक्षण अशक्त त्रुटियों को भ्रमित करने के बजाय विकृत डेटा पर विफल हो जाएं, उन लोगों के लिए प्रतिक्रिया का दस्तावेजीकरण करना जो कभी सर्वर कोड नहीं पढ़ेंगे, और टाइप किए गए क्लाइंट उत्पन्न करना। एक JSON स्कीमा सार्वजनिक प्रतिक्रिया को चुपचाप बदलने से कॉन्फ़िगरेशन परिवर्तन को रोकने का सबसे सस्ता तरीका भी है, क्योंकि सत्यापनकर्ता इसे उत्पादन के बजाय निर्माण समय पर पकड़ लेता है।

                {
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id": { "type": "string", "format": "uuid" },
    "email": { "type": "string", "format": "email" },
    "plan": { "type": "string", "enum": ["free", "pro", "team"] }
  }
}
              

इसे संस्करण नियंत्रण में रखें

जनरेट किए गए स्कीमा उस समय ख़राब हो जाते हैं जब कोई उनका स्वामी नहीं होता। डेटा उत्पन्न करने वाले कोड के बगल में कठोर फ़ाइल को प्रतिबद्ध करें, इसे सीआई में सत्यापनकर्ता से संदर्भित करें, और केवल तभी पुन: उत्पन्न करें जब अनुबंध वास्तव में बदलता है - स्कीमा को आकार के लिए सत्य के स्रोत के रूप में और नमूने को साक्ष्य के रूप में मानें, न कि इसके विपरीत।

ब्राउज़र में अनुमान

वास्तविक पेलोड पहचानकर्ताओं, ईमेल और टोकन से भरे हुए हैं, इसलिए JSON से JSON स्कीमा रूपांतरण जो नमूना अपलोड करता है वह पूरी तरह से यांत्रिक संचालन के लिए उत्पादन डेटा सौंप रहा है। स्थानीय रूप से अनुमान लगाने से पेलोड टैब में रहता है, आपको बिना किसी दूसरे विचार के ग्राहक रिकॉर्ड पेस्ट करने की सुविधा मिलती है, और नेटवर्क कट ऑफ के साथ काम करता है।