डेवलपर टूल · JSON फ़ॉर्मेटर और सत्यापनकर्ता
वेब APआई के लिए डिफ़ॉल्ट प्रारूप के रूप में JSON ने XML को कैसे प्रतिस्थापित किया
· पेजभूमि
json मानकों मान्यकरण
बीस साल पहले XML सिस्टम के बीच भेजी जाने वाली किसी भी चीज़ के लिए अनुमानित प्रारूप था। यह पोस्ट बताती है कि JSON ने इसे वेब APआई में कैसे विस्थापित किया, प्रत्येक प्रारूप किस लिए डिज़ाइन किया गया था, और क्यों XML अभी भी कुछ डोमेन पर हावी है।
एक SOAP समापन बिंदु बचा है
एक SOAP समापन बिंदु बचा है - एक एकीकरण जो एक कोडबेस में XML बोलता है जहां बाकी सब कुछ JSON बोलता है, और सवाल यह है कि हम यहां कैसे पहुंचे। कंट्रास्ट अक्सर क्लाइंट कोड में दिखाई देता है: एक पथ लिफाफे, नामस्थान और उत्पन्न प्रकारों का प्रबंधन करता है, जबकि नए एंडपॉइंट हल्के HTTP पुस्तकालयों के माध्यम से सामान्य वस्तुओं का आदान-प्रदान करते हैं। वह अवलोकन एक स्थानीय वास्तुकला का वर्णन करता है, न कि एक सार्वभौमिक कालक्रम का।
फ़ॉर्मेटर केवल JSON को संभालता है; क्रॉस-फ़ॉर्मेट रूपांतरण अलग सिंटेक्स कन्वर्टर्स पैनल से संबंधित है। JSON की लोकप्रियता XML को अप्रचलित नहीं बनाती है, न ही स्थानीय सुंदर-मुद्रण API अनुबंध को मान्य करता है। यह लेख ऐतिहासिक अपनाने को इस मार्ग पर लागू किए गए संकीर्ण व्यवहार से अलग करता है। निर्णायक तिथियों, कारणों या बाजार-व्यापी प्रतिस्थापन के बारे में असमर्थित ऐतिहासिक दावों को वर्तमान समय की चूक से अनुमान लगाने के बजाय जानबूझकर छोड़ दिया गया है या सही किया गया है।
XML किस लिए बनाया गया था
XML किस लिए बनाया गया था - मिश्रित सामग्री, नामस्थान, स्कीमा और परिवर्तन पाइपलाइन वाले दस्तावेज़। तत्वों में टेक्स्ट और चाइल्ड मार्कअप दोनों हो सकते हैं, विशेषताएँ मेटाडेटा ले जा सकती हैं, और नेमस्पेस-योग्य नाम शब्दावलियों को सह-अस्तित्व में आने देते हैं। XML स्कीमा, XPath और XSLT जैसी प्रौद्योगिकियाँ दस्तावेज़-केंद्रित वर्कफ़्लोज़ में सत्यापन, क्वेरी और परिवर्तन का समर्थन करती हैं।
जब पेलोड एक प्रकाशन, हस्ताक्षरित व्यावसायिक दस्तावेज़ या एक्स्टेंसिबल उद्योग संदेश हो तो वे क्षमताएं अनावश्यक नहीं होती हैं। वे एक साधारण वस्तु-और-सरणी विनिमय की आवश्यकता से अधिक अवधारणाएँ थोपते हैं। इसलिए समकक्ष उदाहरणों की तुलना करने पर अनुबंध पर विचार करना चाहिए, न कि केवल वर्ण गणना पर: XML और JSON विभिन्न मॉडलिंग टूल को उजागर करते हैं, और न ही सिंटैक्स स्वचालित रूप से सही डोमेन शब्दार्थ प्रदान करता है।
ब्राउज़र मूल रूप से क्या कर सकते हैं
ब्राउज़र मूल रूप से क्या कर सकते हैं - XMLHttpRequest या तो पाठ्य प्रारूप को पुनः प्राप्त कर सकता है, और ब्राउज़र XML DOM पार्सिंग की पेशकश करते हैं। आरंभिक JavaScript कोड का मूल्यांकन कभी-कभी JSON-जैसे पाठ के रूप में किया जाता था, जब इनपुट अविश्वसनीय होता था तो यह एक असुरक्षित प्रथा थी; मानकीकृत `JSON.parse` ने बाद में एक समर्पित पार्सर प्रदान किया। JSON मानचित्रों को स्वाभाविक रूप से JavaScript सरणियों, वस्तुओं, स्ट्रिंग्स, संख्याओं, बूलियन और शून्य में पार्स किया गया।
वह मैपिंग कई ब्राउज़र अनुप्रयोगों के लिए समारोह को कम कर देती है, लेकिन यह सबूत नहीं है कि ब्राउज़र XML को संसाधित करने में असमर्थ थे या केवल API ने ही गोद लेने का निर्धारण किया था। XML DOMs स्वचालित रूप से सादे ऑब्जेक्ट बनने के बजाय तत्वों, विशेषताओं और नामस्थानों को संरक्षित करते हैं। कार्य-कारण के बारे में ऐतिहासिक दावों के लिए कार्यान्वयन की सुविधा से परे स्रोतों की आवश्यकता होती है, इसलिए असमर्थित संस्करण यहां छोड़ दिए गए हैं या सही किए गए हैं।
महत्वपूर्ण मोड़ - सार्वजनिक वेब APआई जिसने XML के साथ JSON की पेशकश की, फिर केवल JSON, और अधिकांश नई सेवाओं के लिए REST ने SOAP को विस्थापित कर दिया।
महत्वपूर्ण मोड़ - कई सार्वजनिक वेब APआई ने XML के साथ JSON को उजागर किया, और कई बाद की सेवाओं ने JSON को अपने प्राथमिक प्रतिनिधित्व के रूप में चुना। हल्के HTTP स्टाइल भी एप्लिकेशन APआई के लिए आम हो गए जबकि SOAP स्थापित पारिस्थितिकी तंत्र में बने रहे। सटीक बाज़ार शेयर, प्रथम मूवर्स और तिथियाँ स्रोत के अनुसार भिन्न होती हैं और इस फ़ॉर्मेटर रिपॉजिटरी से स्थापित नहीं की जा सकतीं।
तदनुसार, असमर्थित ऐतिहासिक दावों को एक सुव्यवस्थित एकल-कारण वाली कहानी में परिवर्तित करने के बजाय छोड़ दिया जाता है या सुधार दिया जाता है। रक्षात्मक तंत्र अंतरसंचालनीयता दबाव है: क्लाइंट लाइब्रेरी, दस्तावेज़ीकरण, टूलींग और पड़ोसी सेवाएँ एक प्रारूप को सुदृढ़ करती हैं जब टीमें इसके चारों ओर मानकीकृत हो जाती हैं। वह फीडबैक यह दावा किए बिना स्थानीय डिफ़ॉल्ट की व्याख्या कर सकता है कि XML गायब हो गया है या प्रत्येक REST API JSON का उपयोग करता है।
स्विच की लागत
स्विच की लागत - JSON में विशेषताओं और चाइल्ड तत्वों के बीच कोई मूल अंतर नहीं है, कोई मिश्रित-सामग्री मॉडल नहीं है और कोई टिप्पणी वाक्यविन्यास नहीं है। आधार JSON व्याकरण भी किCAप्लिकेशन स्कीमा को परिभाषित नहीं करता है। जिन टीमों को अनुबंधों की आवश्यकता होती है, वे अलग-अलग सिस्टम जैसे JSON स्कीमा या ओपनAPआई जोड़ते हैं, प्रत्येक की अपनी शब्दावली, टूलींग और संस्करण निर्णय होते हैं।
जब तक मैपिंग स्पष्ट रूप से डिज़ाइन नहीं की जाती तब तक रूपांतरण जानकारी खो सकता है। बार-बार दोहराए गए XML तत्व सरणी बन सकते हैं, नेमस्पेस-योग्य नामों को प्रतिनिधित्व की आवश्यकता होती है, और मार्कअप के साथ इंटरलीव किया गया टेक्स्ट हमेशा एक सरल वस्तु नहीं बन सकता है। सरल पेलोड सिंटैक्स कुछ जटिलता को बाहरी अनुबंधों या सम्मेलनों में ले जाता है; यह सत्यापन, विकास और दस्तावेज़ीकरण को अनावश्यक नहीं बनाता है।
जहां XML अभी भी जीतता है
जहां XML अभी भी जीतता है - प्रकाशन वर्कफ़्लो मिश्रित सामग्री और स्थापित दस्तावेज़ शब्दावली से लाभान्वित होता है, जबकि कार्यालय प्रारूप समृद्ध दस्तावेज़ों का प्रतिनिधित्व करने के लिए XML भागों को पैकेज करता है। परिपक्व वित्त और उद्यम संदेश मानक नामस्थान, स्कीमा, हस्ताक्षर या दीर्घकालिक टूलींग निवेश पर निर्भर हो सकते हैं। सिंटैक्स को बदलने के लिए पारिस्थितिकी तंत्र समन्वय की आवश्यकता होगी, न कि केवल एक छोटे नमूना पेलोड की।
XML तब भी उपयोगी होता है जब परिवर्तन और पथ-आधारित क्वेरीज़ वर्कफ़्लो के केंद्र में होती हैं। JSON अतिरिक्त सम्मेलनों के साथ इन डोमेन की सेवा कर सकता है, जैसे XML सामान्य APआई की सेवा कर सकता है, लेकिन माइग्रेशन मूल्य अनुबंध और टूलींग लागत से अधिक होना चाहिए। ब्राउज़र-फ़ेसिंग सेवाओं में लोकप्रियता हर प्रतिनिधित्व समस्या के लिए श्रेष्ठता का प्रमाण नहीं है, और कुल विस्थापन के असमर्थित दावों को सही या छोड़ दिया जाता है।
इसमें क्या शामिल नहीं है
इसमें क्या शामिल नहीं है - प्रोटोकॉल बफ़र्स और मैसेजपैक जैसे बाइनरी विकल्प, जो विभिन्न शर्तों पर प्रतिस्पर्धा करते हैं। उनके तार का आकार, स्कीमा आवश्यकताएँ, स्ट्रीमिंग व्यवहार और टूलींग को अलग मूल्यांकन की आवश्यकता है। न ही यह हाइपरमीडिया सम्मेलनों, ट्रांसपोर्ट प्रोटोकॉल या API शैलियों की तुलना करता है; SOAP बनाम REST केवल XML बनाम JSON नहीं है, और कोई भी प्रतिनिधित्व HTTP से अधिक यात्रा कर सकता है।
यह API गोद लेने का स्रोतित मात्रात्मक इतिहास भी नहीं है। दिनांक, प्रतिशत, प्रथम कार्यान्वयन या उद्योग-व्यापी कारणों के बारे में सटीक विवरण सूचीबद्ध रिपोजिटरी साक्ष्य द्वारा समर्थित नहीं हैं, इसलिए उन्हें छोड़ दिया गया है या सही किया गया है। इसके बजाय लेख उन परिणामों को संपूर्ण ऐतिहासिक कथा के प्रमाण के रूप में प्रस्तुत किए बिना अवलोकन योग्य प्रारूप क्षमताओं और प्रशंसनीय इंजीनियरिंग परिणामों की व्याख्या करता है।
टेकअवे: JSON ने सादगी पर जीत हासिल की, संपूर्णता पर नहीं
टेकअवे: JSON एक कॉम्पैक्ट डेटा मॉडल, मुख्यधारा की भाषाओं में प्रत्यक्ष समर्थन और व्यापक आसपास के टूलींग के माध्यम से कई वेब APआई के लिए सामान्य डिफ़ॉल्ट बन गया, इसलिए नहीं कि इसमें XML द्वारा प्रदान की जाने वाली प्रत्येक सुविधा शामिल है। XML वहां उपयुक्त रहता है जहां दस्तावेज़ संरचना, नामस्थान, परिवर्तन या स्थापित स्कीमा केंद्रीय होते हैं। प्रारूप का चयन सार्वभौमिक रैंकिंग के बजाय अनुबंध और पारिस्थितिकी तंत्र का अनुसरण करता है।
ToolAcre इस मार्ग पर JSON को पार्सिंग, सत्यापन और सुंदर-मुद्रण द्वारा JSON के संकीर्ण मॉडल को दर्शाता है; यह API शब्दार्थ को प्रमाणित नहीं करता है या XML को अप्रचलित नहीं बनाता है। क्रॉस-फ़ॉर्मेट रूपांतरण का उपयोग केवल तभी करें जब एक परिभाषित मैपिंग आवश्यक जानकारी को संरक्षित करती है। इतिहास को भी समान रूप से सावधान रखें: एकल मोड़ या पूर्ण प्रतिस्थापन के बारे में असमर्थित दावों को छोड़ दिया जाता है या सही कर दिया जाता है, जिससे तंत्र और वर्तमान व्यवहार का बचाव किया जा सकता है।