JSON बनाम YAML बनाम XML: असल में किसे कब इस्तेमाल करें

JSON, YAML और XML — तीनों मूल रूप से एक जैसा डेटा दिखाने में सक्षम हैं — नेस्टेड ऑब्जेक्ट, लिस्ट, की-वैल्यू पेयर, सादे वैल्यू — और यही वजह है कि इनके बीच चुनाव अक्सर आदत पर या किसी फ़्रेमवर्क के डिफ़ॉल्ट पर टिक जाता है, न कि किसी सोचे-समझे फ़ैसले पर। लेकिन ये तीनों अलग-अलग समय पर, अलग-अलग मुख्य इस्तेमाल के लिए डिज़ाइन किए गए थे, और वे मूल डिज़ाइन लक्ष्य आज भी असली, व्यावहारिक फ़र्क़ के रूप में सामने आते हैं: कौन सा हाथ से एडिट करने में सुहाना लगता है, किसे कोई मशीन सख़्ती से वैलिडेट कर सकती है, कौन सा गहराई तक नेस्ट होने पर भी पढ़ने लायक़ बना रहता है, और किसके लिए टूल का पूरा इकोसिस्टम पहले से तैयार है। इन्हीं फ़र्क़ों के आधार पर चुनना, न कि आदत के आधार पर, वह असली चीज़ है जो किसी फ़ॉर्मेट के चुनाव को सिर्फ़ पारंपरिक की बजाय वाक़ई अच्छा बनाती है।

JSON सीधे JavaScript के ऑब्जेक्ट-लिटरल सिंटैक्स से निकाला गया था, और यही मूल वजह है कि यह वेब API के लिए डिफ़ॉल्ट डेटा-इंटरचेंज फ़ॉर्मेट बना: कोई भी JavaScript एनवायरनमेंट इसे बिना किसी लाइब्रेरी के नैटिवली पार्स कर सकता है, इसका ग्रामर इतना छोटा है कि लगभग किसी भी दूसरी भाषा में एक दोपहर में सही ढंग से इम्प्लीमेंट किया जा सकता है, और इसके सख़्त नियम — कोई कमेंट नहीं, कोई ट्रेलिंग कॉमा नहीं, सिर्फ़ डबल-कोटेड की — का मतलब है कि किसी JSON पार्सर को सुलझाने के लिए बहुत कम अस्पष्टता मिलती है, जिससे JSON पार्स करने में तेज़ और सही तरीक़े से जनरेट करने में आसान दोनों होता है। यही सख़्ती किसी इंसान के हाथ से सीधे एडिट करने वाली किसी भी चीज़ के लिए JSON की सबसे बड़ी कमज़ोरी भी है: कमेंट न होने का मतलब है किसी कॉन्फ़िगरेशन फ़ाइल में समझाने वाला नोट छोड़ने का कोई तरीक़ा न होना, और पंक्चुएशन से भरा नेस्टेड-ब्रेस सिंटैक्स तब वाक़ई नज़रों से ट्रैक करना मुश्किल हो जाता है जब कोई बनावट तीन-चार लेवल से ज़्यादा गहराई में नेस्ट हो जाए।

यही वजह है कि JSON मशीन-से-मशीन संचार पर राज करता है — API रिस्पॉन्स, सर्विसेज़ के बीच डेटा इंटरचेंज, वह हर चीज़ जो मुख्य रूप से कोड द्वारा जनरेट और इस्तेमाल होती है, न कि किसी इंसान द्वारा पढ़ी और एडिट की जाती है — जबकि उन कॉन्फ़िगरेशन फ़ाइलों के लिए यह कुछ अजीब चुनाव बना रहता है जिन्हें किसी इंसान को हाथ से मेंटेन करना होता है।

YAML को उलटी प्राथमिकता के साथ डिज़ाइन किया गया था: इंसानी पठनीयता और हाथ से एडिट करने में आसानी, इसकी क़ीमत JSON से कहीं ज़्यादा जटिल पार्सिंग स्पेसिफ़िकेशन के रूप में चुकाई गई। यह नेस्टिंग दिखाने के लिए ब्रेस की बजाय इंडेंटेशन इस्तेमाल करता है, `#` से असली कमेंट सपोर्ट करता है, और आम मामलों में बिना कोट वाली स्ट्रिंग की इजाज़त देता है — यह सब मिलकर किसी अच्छी तरह फ़ॉर्मेट की गई YAML फ़ाइल को कोड की बजाय लगभग सादे, स्ट्रक्चर्ड नोट्स जैसा बना देता है — यही वजह है कि YAML डेवलपर टूलिंग के एक बड़े हिस्से में कॉन्फ़िगरेशन फ़ाइलों के लिए डिफ़ॉल्ट बन गया: CI/CD पाइपलाइन डेफ़िनिशन, कंटेनर ऑर्केस्ट्रेशन मैनिफ़ेस्ट, ऐप्लिकेशन कॉन्फ़िगरेशन जिसे किसी इंसान को वाक़ई पढ़ना और सीधे बदलना पड़ता है। इसका ट्रेड-ऑफ़ यह है कि बनावट के लिए व्हाइटस्पेस पर YAML की निर्भरता इसे हाथ से सही ढंग से एडिट करने में वाक़ई नाज़ुक बना देती है — एक ग़लत जगह पर लगा इंडेंट चुपचाप यह बदल देता है कि कोई ब्लॉक किसका हिस्सा है, बिना कोई साफ़ एरर दिए — और इसका ज़्यादा ढीला, फ़ीचर-भरपूर स्पेसिफ़िकेशन सालों में अलग-अलग YAML लाइब्रेरी के बीच असली, दस्तावेज़ीकृत पार्सिंग असंगतियाँ पैदा कर चुका है — ऐसी अस्पष्टता जिसके लिए JSON का कहीं ज़्यादा सख़्त ग्रामर कोई जगह ही नहीं छोड़ता।

XML, JSON और YAML दोनों से पुराना है और इसे फिर एक अलग प्राथमिकता के लिए डिज़ाइन किया गया था: सख़्त, वेरिफ़ाई किए जा सकने वाला दस्तावेज़ ढाँचा, इसके आस-पास खड़े स्टैंडर्ड के एक परिपक्व इकोसिस्टम के साथ — स्कीमा लैंग्वेज जो किसी ऐप्लिकेशन कोड के छूने से पहले ही किसी दस्तावेज़ की बनावट को वैलिडेट कर सकती हैं, दस्तावेज़ के अंदर क्वेरी करने के लिए XPath, अलग-अलग स्रोतों से आई शब्दावली को नाम-टकराव के बिना मिलाने के लिए नेमस्पेस। टूलिंग की यह गहराई एंटरप्राइज़ और दस्तावेज़-केंद्रित संदर्भों में आज भी वाक़ई JSON या YAML से बेजोड़ है: सख़्त डेटा-इंटरचेंज ज़रूरतों वाली इंडस्ट्रीज़, स्टैंडर्डाइज़्ड डॉक्यूमेंट फ़ॉर्मेट, और इसके इर्द-गिर्द बने लंबे समय से चले आ रहे लेगेसी सिस्टम आज भी XML पर भरोसा करते हैं, ठीक इसी वैलिडेशन और टूलिंग परिपक्वता की वजह से, महज़ जड़ता की वजह से नहीं। इसका जाना-पहचाना ट्रेड-ऑफ़ वर्बोसिटी है — XML में वही नेस्टेड डेटा दिखाने के लिए आमतौर पर बराबर के JSON से साफ़ तौर पर ज़्यादा कैरेक्टर लगते हैं, क्योंकि हर वैल्यू को एक पंक्चुएशन कैरेक्टर की बजाय एक ओपनिंग और क्लोज़िंग टैग चाहिए होता है — यही मुख्य वजह है कि जैसे-जैसे वेब सर्विसेज़ परिपक्व हुईं और पेलोड साइज़ व पार्सिंग की सादगी दस्तावेज़-शैली वैलिडेशन से बड़ी प्राथमिकता बनते गए, XML ने डिफ़ॉल्ट-API-फ़ॉर्मेट की भूमिका JSON के हाथों गँवा दी।

किसी API रिक्वेस्ट या रिस्पॉन्स बॉडी के लिए, JSON आज लगभग हमेशा सही डिफ़ॉल्ट है — यही वह चीज़ है जिसकी उम्मीद ज़्यादातर क्लाइंट लाइब्रेरी, ज़्यादातर डॉक्यूमेंटेशन टूलिंग, और किसी इंटीग्रेशन के दूसरे छोर पर बैठे ज़्यादातर डेवलपर बिना किसी घर्षण के करते हैं। किसी ऐसी कॉन्फ़िगरेशन फ़ाइल के लिए जिसे कोई इंसान नियमित रूप से पढ़ने और हाथ से एडिट करने वाला है — CI पाइपलाइन, ऐप्लिकेशन कॉन्फ़िग, इन्फ़्रास्ट्रक्चर-ऐज़-कोड डेफ़िनिशन — YAML के कमेंट और साफ़-सुथरी नेस्टिंग वाक़ई अपना मोल वसूल करते हैं, बशर्ते इसके आस-पास की टूलिंग सिंटैक्स को ध्यान से वैलिडेट करे, क्योंकि यहीं YAML की व्हाइटस्पेस-नाज़ुकता सबसे ज़्यादा काटती है। किसी दस्तावेज़-केंद्रित फ़ॉर्मेट के लिए जिसे सख़्त स्कीमा वैलिडेशन, मिली-जुली शब्दावली में नेमस्पेसिंग, या किसी मौजूदा XML-आधारित एंटरप्राइज़ सिस्टम से इंटीग्रेशन की असली ज़रूरत हो, XML की वर्बोसिटी उस टूलिंग परिपक्वता की उचित क़ीमत है जिसे बाक़ी दोनों में से कोई भी पूरी तरह नहीं दोहरा पाता। जो फ़ॉर्मेट चुनाव किसी प्रोजेक्ट की वाक़ई अच्छी सेवा करता है, वह वही है जो इस बात से मेल खाता हो कि फ़ाइल को सबसे ज़्यादा कौन — या क्या — पढ़ने और लिखने वाला है, न कि जो उस पल का सबसे फ़ैशनेबल डिफ़ॉल्ट हो।