डेवलपर टूल · JSON फ़ॉर्मेटर और सत्यापनकर्ता
मान्य JSON बनाम स्कीमा के विरुद्ध मान्य: 'वैध' के दो अर्थ
· पेजभूमि
json मानकों मान्यकरण
एक सत्यापनकर्ता यह कहता है कि आपका JSON वैध है, इसका मतलब केवल यह है कि वह पार्स करता है। यह पोस्ट वैधता के स्तर (वाक्यविन्यास, संरचना, शब्दार्थ) और क्यों JSON स्कीमा व्याकरण से परे हर चीज के लिए मौजूद है, बताती है।
मान्य, और फिर भी अस्वीकृत
एक अनुरोध त्रुटिहीन JSON हो सकता है और फिर भी API के लिए अस्वीकार्य हो सकता है। `{"username":"nori","plan":"gold"}` में संतुलित सीमांकक, उद्धृत नाम और कानूनी मूल्य हैं, फिर भी किसी सेवा के लिए ईमेल की आवश्यकता हो सकती है, योजना के नाम को अस्वीकार कर दिया जा सकता है या वर्तमान स्थिति में खाता निर्माण पर रोक लगाई जा सकती है। पार्सर और एप्लिकेशन अलग-अलग प्रश्नों का उत्तर दे रहे हैं, इसलिए दोनों परिणाम सही हो सकते हैं।
ToolAcre केवल पहले प्रश्न का उत्तर देता है: क्या इस पाठ को इसकी इनपुट सीमा के भीतर सख्त JSON के रूप में पार्स किया जा सकता है? यह कोई स्कीमा लोड नहीं करता है, आवश्यक गुणों की जांच नहीं करता है, प्रारूपों को सत्यापित नहीं करता है, किसी डेटाबेस से संपर्क नहीं करता है या व्यावसायिक नियमों का मूल्यांकन नहीं करता है। जब टूल वैध कहता है, तो उसे "अच्छी तरह से निर्मित JSON सिंटैक्स" के रूप में पढ़ें, न कि सिस्टम से अनुमोदन के रूप में जो मूल्य का उपभोग करेगा।
स्तर एक: सुगठित वाक्यविन्यास
सिंटैक्स सत्यापन JSON व्याकरण की जाँच करता है: एक शीर्ष-स्तरीय मान, सही ढंग से युग्मित कंटेनर, उद्धृत ऑब्जेक्ट नाम, वैध अल्पविराम और कोलन, कानूनी स्ट्रिंग, कानूनी संख्या और सटीक अक्षर। यह `NaN` और `Infinity`, टिप्पणियाँ, अनुवर्ती अल्पविराम और एकल-उद्धृत स्ट्रिंग को अस्वीकार करता है। यह किसी भी व्याकरण-मान्य आकार को स्वीकार करता है, जिसमें एक अकेली संख्या या अपरिचित क्षेत्रों वाली वस्तु शामिल है।
विकृत स्रोत में एक पाठ्य विफलता बिंदु है, इसलिए ToolAcre पहले असंभव वर्ण के लिए एक पंक्ति और स्तंभ की रिपोर्ट कर सकता है। एक गुम अल्पविराम के कारण अगला उद्धरण रिपोर्ट किया जा सकता है; अनुगामी अल्पविराम के कारण समापन सीमांकक की सूचना दी जा सकती है। सिंटैक्स को ठीक करने से एक पार्स करने योग्य मान बनता है लेकिन यह स्थापित नहीं होता है कि मान का आकार या अर्थ किसी अन्य प्रोग्राम द्वारा अपेक्षित है।
स्तर दो: आकार
आकार सत्यापन पूछता है कि क्या पार्स किया गया मान घोषित अनुबंध से मेल खाता है। उपयोगकर्ता स्कीमा के लिए `email` की आवश्यकता हो सकती है, `age` को कम से कम 18 तक सीमित करना, `tier` को `free` या `pro` तक सीमित करना और अज्ञात संपत्तियों को अस्वीकार करना। `{"email":false,"tier":"gold"}` वैध JSON सिंटैक्स है लेकिन उन संरचनात्मक नियमों में विफल रहता है क्योंकि मान प्रकार और अनुमत विकल्प गलत हैं।
JSON स्कीमा ऐसी बाधाओं को व्यक्त करने का एक तरीका है, लेकिन ToolAcre इसे निष्पादित नहीं करता है। एक स्कीमा सत्यापनकर्ता आमतौर पर एक उदाहरण पथ जैसे `/tier`, एक कीवर्ड जैसे `enum`, और एक पार्सर कैरेट के बजाय एक व्याख्यात्मक संदेश रिपोर्ट करता है। इस स्तर का निदान करते समय स्कीमा संस्करण और API अनुबंध को पेलोड के पास रखें; विराम चिह्न बदलने से गलत आकार का सही ढंग से पार्स किया गया मान ठीक नहीं होगा।
स्तर तीन: अर्थ
अर्थ दस्तावेज़ के स्थिर आकार से परे तथ्यों और नियमों पर निर्भर करता है। किसी खाते का नामकरण करते समय `accountId` में सही स्ट्रिंग पैटर्न हो सकता है। आरंभ तिथि अंतिम तिथि के बाद आने पर ISO-शैली प्रारूप से मेल खा सकती है। एक मात्रा सकारात्मक हो सकती है फिर भी वर्तमान स्टॉक से अधिक हो सकती है। इन विफलताओं के लिए एप्लिकेशन संदर्भ, संग्रहीत स्थिति या फ़ील्ड के बीच संबंधों की आवश्यकता होती है।
कुछ अर्थ संबंधी बाधाओं को एक स्कीमा में अनुमानित किया जा सकता है, लेकिन कई सेवा तर्क में हैं जहां आधिकारिक डेटा और लेनदेन स्थिति उपलब्ध हैं। इस स्तर पर त्रुटि प्रतिक्रियाओं को JSON पाठ के विकृत होने का दिखावा किए बिना प्रासंगिक फ़ील्ड या नियम की पहचान करनी चाहिए। ToolAcre उन निर्णयों को पुन: प्रस्तुत नहीं कर सकता क्योंकि यह न तो अनुबंध को जानता है और न ही उस एप्लिकेशन को इनपुट भेजता है जो व्यवसाय नियम का स्वामी है।
कार्यान्वित उदाहरण: तीन चेक के माध्यम से एक पेलोड
`{"sku":"A-19","quantity":3,"warehouse":"north"}` से प्रारंभ करें. ToolAcre इसे स्वीकार करता है: सभी नाम और मान JSON व्याकरण का पालन करते हैं। एक स्कीमा को तब एक ऑब्जेक्ट, एक गैर-रिक्त स्ट्रिंग SKU, एक सकारात्मक पूर्णांक मात्रा और दस्तावेज़ित वेयरहाउस कोड में से एक की आवश्यकता हो सकती है। मान लीजिए कि यह पेलोड उन बाधाओं को भी पार कर जाता है। किसी भी जांच ने पुष्टि नहीं की है कि SKU A-19 मौजूद है या उत्तर में तीन इकाइयाँ हैं।
इन्वेंट्री सेवा वर्तमान रिकॉर्ड के विरुद्ध तीसरी जांच करती है और अनुपलब्ध के रूप में अनुरोध को अस्वीकार कर सकती है। इंडेंटेशन बदलने से उस परिणाम में बदलाव नहीं हो सकता। यदि `quantity` को `03` के रूप में लिखा जाता, तो सिंटैक्स पहले विफल हो जाता; यदि यह `"3"` होता, तो पार्सिंग पास हो जाती लेकिन स्कीमा प्रकार की जाँच विफल हो जाती; संख्यात्मक `3` के साथ, केवल पशुधन नियम ही रहता है। इसलिए एक ही क्षेत्र तीन अलग-अलग कारणों से तीन अलग-अलग परतों में विफल हो सकता है।
जहां प्रत्येक चेक का संबंध है
संपादन करते समय जितनी जल्दी हो सके सिंटैक्स सत्यापन चलाएँ, क्योंकि बाद में जाँच उस पाठ पर विश्वसनीय रूप से काम नहीं कर सकती जो पार्स नहीं करता है। यह मानने के बजाय कि ग्राहक ने पहले ही ऐसा कर लिया है, प्रत्येक अविश्वसनीय एप्लिकेशन सीमा पर घोषित आकार को लागू करें। उस घटक में व्यावसायिक अपरिवर्तनीयों का मूल्यांकन करें जो आवश्यक स्थिति का स्वामी है, खासकर जब उत्तर अनुरोधों के बीच बदल सकता है।
क्लाइंट-साइड चेक फीडबैक में सुधार करते हैं लेकिन सर्वर-साइड प्रवर्तन को प्रतिस्थापित नहीं करते हैं। इसके विपरीत, "अमान्य JSON" कहने वाली सर्वर प्रतिक्रिया को प्रत्येक अस्वीकृत अनुरोध के लिए उपयोग करने के बजाय पार्सिंग विफलता के लिए आरक्षित किया जाना चाहिए। स्पष्ट पृथक्करण उपयोगी निदान उत्पन्न करता है: वाक्यविन्यास के लिए रेखा और स्तंभ, संरचनात्मक बाधाओं के लिए उदाहरण पथ, और अर्थ संबंधी संघर्षों के लिए डोमेन-विशिष्ट कोड या संदेश। ToolAcre केवल प्रथम कैटेगरी की आपूर्ति करता है।
इसमें क्या शामिल नहीं है
यह फ़ॉर्मेटर JSON स्कीम का लेखक या मूल्यांकन नहीं करता है, स्कीमा ड्राफ्ट का चयन नहीं करता है, स्कीमा संदर्भों को हल नहीं करता है, डिफ़ॉल्ट सम्मिलित नहीं करता है या संख्याओं में स्ट्रिंग को बाध्य नहीं करता है। यह API के OpenAPI दस्तावेज़ या कस्टम सत्यापन सम्मेलनों को भी नहीं जानता है। इनपुट के साथ एक स्कीमा प्रदान करने से ToolAcre का परिणाम नहीं बदलेगा क्योंकि इस टूल में कोई स्कीमा-प्रसंस्करण चरण नहीं है।
सिंटैक्स सत्यापन भी यहां डुप्लिकेट ऑब्जेक्ट नामों का पता नहीं लगाता है; `JSON.parse` फ़ॉर्मेटिंग से पहले अंतिम घटना रखता है। न ही यह संख्यात्मक परिशुद्धता, विहित बाइट्स, सुरक्षित प्रतिपादन या प्राधिकरण की गारंटी देता है। उनमें से प्रत्येक चिंता को अपने स्वयं के अनुबंध और कार्यान्वयन की आवश्यकता है। उन्हें एक हरे "वैध" बैज में संपीड़ित करने से बचें, क्योंकि ऐसा करने से यह छिप जाता है कि कौन से साक्ष्य एकत्र किए गए थे और कौन से प्रश्न कभी नहीं पूछे गए थे।
टेकअवे: 'वैध' के लिए एक क्वालीफायर की आवश्यकता होती है
प्रत्येक सत्यापन दावे को योग्य बनाएं। "मान्य JSON" का अर्थ है कि पाठ व्याकरण का पालन करता है। "इस स्कीमा के विरुद्ध मान्य" का अर्थ है कि पार्स किया गया मूल्य नामित संरचनात्मक अनुबंध को संतुष्ट करता है। "सेवा द्वारा स्वीकृत" का अर्थ है कि वर्तमान आवेदन नियम संचालन की अनुमति देते हैं। कई कार्यप्रवाहों में एक परत को पारित करना अगली के लिए आवश्यक है, लेकिन यह कभी भी इस बात का प्रमाण नहीं है कि बाद की सभी परतें पारित हो गईं।
सख्त सिंटैक्स को प्रारूपित करने और जांचने के लिए ToolAcre का उपयोग करें, जिसमें `NaN` और `Infinity` जैसे गैर-JSON अक्षर की अस्वीकृति भी शामिल है। फिर उस स्कीमा और एप्लिकेशन का उपयोग करें जो वास्तव में पेलोड को नियंत्रित करता है। जब कोई अनुरोध अभी भी विफल रहता है, तो बार-बार सही JSON को पुन: स्वरूपित करने के बजाय त्रुटि को उसकी अपनी परत पर पढ़ें। टूल में कोई स्कीमा जांच नहीं है, और वह स्पष्ट सीमा वैधता के व्यापक वादे से अधिक उपयोगी है।