JSON काफी अलग-अलग भूमिकाओं में दिखाई देता है कि इन्हें अलग करना उपयोगी है: प्रारूप हर जगह एक ही है, लेकिन प्रत्येक उपयोग के मामले को वास्तव में उससे क्या चाहिए वह अलग है, और एक को दूसरे से भ्रमित करना अजीब निर्णयों का एक सामान्य स्रोत है (एक मशीन-जनरेटेड API payload में टिप्पणियाँ जोड़ना, या यह उम्मीद करना कि एक NDJSON लॉग पाइपलाइन एक JSON दस्तावेज़ के रूप में पार्स होगी)।
REST API payloads
मात्रा के हिसाब से सबसे सामान्य उपयोग का मामला। एक अनुरोध बॉडी और
एक प्रतिक्रिया बॉडी प्रत्येक एक JSON दस्तावेज़ हैं, Content-Type: application/json, एक पक्ष द्वारा जनरेट और दूसरे पक्ष द्वारा उपभोग
किया जाता है बिना किसी मानव के बीच में पढ़े। यहाँ कुछ भी टिप्पणियों
या हैंड-एडिटिंग सुविधा की आवश्यकता नहीं है; जो चाहिए वह एक अस्पष्ट
व्याकरण है जिसे हर भाषा एक ही तरह से पार्स करती है, जो JSON की
वास्तविक शक्ति है। एक REST payload वह आकार भी है जिसके लिए JSON Schema
Validator मौजूद है: API के अनुबंध
के विरुद्ध एक प्रतिक्रिया की जांच करें, और ठीक देखें कि कौन सा फ़ील्ड
उसका उल्लंघन करता है और क्यों, इससे पहले कि वह बग उत्पादन कोड में
पहुँचे जो मान लेता है कि फ़ील्ड वहाँ है।
एप्लिकेशन कॉन्फ़िगरेशन
package.json, tsconfig.json, composer.json, और दर्जनों उपकरण
कॉन्फ़िग्स इसके अलावा। यह वह एक उपयोग का मामला है जहाँ JSON की
टिप्पणियों की कमी वास्तव में कुछ खर्च करती है: कोई सेटिंग बिना
किसी स्पष्टीकरण के, क्योंकि प्रारूप में उसे रखने के लिए कहीं नहीं
है। कुछ उपकरण इसे // comment कुंजी के साथ दूर करते हैं जिसे कोई
प्रोग्रामेटिक रूप से नहीं पढ़ता, अन्य YAML या एक JSON सुपरसेट
(JSON5, JSONC) पर स्विच करते हैं जो टिप्पणियों को वापस जोड़ता है।
JSON vs YAML पूर्ण ट्रेड-ऑफ़ के लिए देखें; संक्षिप्त
संस्करण यह है कि हैंड-एडिटेड कॉन्फ़िग फ़ाइलें अक्सर YAML की
टिप्पणियों से लाभान्वित होती हैं, जबकि उपकरणों द्वारा पूरी तरह से
जनरेट और उपभोग की जाने वाली कॉन्फ़िग साधारण JSON के रूप में ठीक है।
NoSQL और दस्तावेज़ डेटाबेस
MongoDB दस्तावेज़ों को BSON के रूप में संग्रहित करता है, एक बाइनरी प्रारूप जो JSON के डेटा मॉडल का सुपरसेट है, और जब आप इसे क्वेरी करते हैं तो JSON (या JSON-जैसी शेल सिंटैक्स) लौटाता है। CouchDB और अधिकांश दस्तावेज़ स्टोर JSON को सीधे स्वीकार और लौटाते हैं। यहाँ आकर्षण संरचनात्मक है: एक दस्तावेज़ डेटाबेस का पूरा पिच डेटा को लगभग उस आकार में संग्रहित करना है जिसमें आपका एप्लिकेशन पहले से उसका उपयोग करता है, बजाय इसके कि उसे पहले रो और फ़ॉरेन कुंजी में सामान्यीकृत किया जाए, और JSON का ऑब्जेक्ट-एंड-एरे मॉडल अधिकांश भाषाओं के नेटिव प्रकारों के काफी करीब है कि अनुवाद लगभग मुफ्त है।
लॉग लाइनें और स्ट्रीमिंग डेटा: NDJSON
एकल JSON दस्तावेज़ अच्छी तरह से स्ट्रीम नहीं होता: एक पार्सर को आमतौर पर कोई मान उत्पन्न करने से पहले पूरे चीज़ की आवश्यकता होती है, क्योंकि एक दस्तावेज़ केवल तभी मान्य है जब इसका अंतिम क्लोज़िंग ब्रेस आ जाता है। Newline Delimited JSON (NDJSON) इसे हल करता है हर लाइन को अपना स्वतंत्र, पूर्ण JSON मान बनाकर, इसलिए एक लॉग पाइपलाइन, एक Kafka टॉपिक, या एक बड़ा एक्सपोर्ट पूरी फ़ाइल को मेमोरी में रखे बिना एक लाइन एक बार में प्रोसेस किया जा सकता है। JSON to NDJSON Converter एक JSON एरे को इस लाइन-प्रति-रिकॉर्ड प्रारूप में और वापस बदलता है, एक ऐसी स्ट्रीम के लिए रिकवरी के साथ जिसमें बीच में एक विकृत लाइन है बजाय एक खराब रिकॉर्ड के लिए पूरी फ़ाइल को विफल करने के।
ब्राउज़र स्टोरेज
localStorage और sessionStorage केवल स्ट्रिंग्स संग्रहित करते हैं;
कुछ भी संरचित JSON.stringify(value) के रूप में जाता है और
JSON.parse(stored) के रूप में वापस आता है। यह वह जगह भी है जहाँ
संख्या सटीकता की समस्या जिसे JSON Data Types
Explained कवर करता है एक वास्तविक बग बन जाती
है बजाय एक जिज्ञासा के: ब्राउज़र के अपने JSON.parse के माध्यम से
localStorage के माध्यम से एक बड़े पूर्णांक ID का round-trip चुपचाप
मान बदल सकता है, जो ठीक वह फ़ेल्योर मोड है जिसके लिए इस साइट के
अपने उपकरण बनाए गए हैं ताकि इसे रिपोर्ट किया जाए बजाय पुनरुत्पादन
के।
अपने डेटा के साथ इसे आज़माना
ऊपर उल्लिखित हर उपकरण पूरी तरह से आपके ब्राउज़र में चलता है: JSON Formatter, NDJSON converter, या Schema Validator में पेस्ट की गई कोई भी चीज़ कहीं भी अपलोड नहीं होती, जो ठीक उस प्रकार के वास्तविक API प्रतिक्रियाओं और कॉन्फ़िग फ़ाइलों के लिए सबसे महत्वपूर्ण है जिनके बारे में यह पृष्ठ है।