JSON Pointer और JSONPath दोनों JSON दस्तावेज़ के अंदर स्थानों को संबोधित करते हैं, और
दोनों एक ही प्रकार के उपकरणों में दिखाई देते हैं: JSON Schema में $ref, PATCH
ऑपरेशन, पथ-आधारित अंतर। वे अलग-अलग समस्याओं को हल करते हैं, और यह जानना कि
दिए गए कार्य को वास्तव में किसकी आवश्यकता है गलत उपकरण चुनने से बचाता है।
JSON Pointer: एक स्थान, RFC 6901
एक pointer / से अलग किए गए टोकन की एक श्रृंखला है: /user/name का अर्थ है
user ऑब्जेक्ट के अंदर name कुंजी, /items/0 का अर्थ है items
एरे का पहला एलीमेंट। एक टोकन के अंदर दो वर्णों को एस्केप करने की आवश्यकता होती है (~1 एक
literal / के लिए, ~0 एक literal ~ के लिए), और खाली स्ट्रिंग pointer के रूप में
पूरे दस्तावेज़ का मतलब है। यह पूरी व्याकरण है। एक pointer ठीक
एक मान को हल करता है, या विफल होता है, बीच में कुछ नहीं: कोई वाइल्डकार्ड नहीं,
कोई फ़िल्टर नहीं, एक से अधिक स्थान से मेल खाने का कोई तरीका नहीं जिसे यह नाम देता है।
{ "user": { "name": "Ada", "roles": ["admin", "editor"] } }
/user/name "Ada" को हल करता है। /user/roles/1 "editor" को हल करता है।
/user/email विफल होता है, क्योंकि वह कुंजी मौजूद नहीं है। Pointer
वाक्यविन्यास में कुछ भी एक ही अभिव्यक्ति में “हर भूमिका” माँगने के लिए नहीं कह सकता;
कॉलर को पहले से इंडेक्स जानना होगा।
JSONPath: एक क्वेरी भाषा
JSONPath, RFC 9535 के रूप में मानकीकृत, मेल खाने के लिए बनाया गया है, न कि
केवल संबोधित करने के लिए। $.userroles[*] ऊपर दिए गए उदाहरण में दोनों भूमिकाओं को एक
क्वेरी में लौटाता है। $..email दस्तावेज़ के हर स्तर पर email नामक किसी भी कुंजी की खोज करता है,
चाहे वह कितना भी गहरा क्यों न हो। फ़िल्टर अभिव्यक्तियाँ जैसे
$.items[?(@.price > 100)] अपनी सामग्री पर शर्त के आधार पर एरे एलीमेंट्स का चयन करती हैं। एक JSONPath क्वेरी शून्य मिलान, एक, या कई लौटा सकती है, जो
pointer के हल-या-विफल अनुबंध से मूलभूत रूप से भिन्न है।
व्यावहारिक अंतर
एक pointer एक स्थान का नाम देता है जिसे आप पहले से जानते हैं। एक JSONPath क्वेरी एक शर्त का वर्णन करती है और इंजन को वह खोजने देती है जो इसे संतुष्ट करता है। वह अंतर तय करता है कि कौन सा दिए गए कार्य के लिए उपयुक्त है:
- आप पहले से जानते हैं कि आपको कौन सा मान चाहिए (“शिपिंग पते एरे का तीसरा एलीमेंट”): pointer का उपयोग करें। यह सरल है, प्रति दस्तावेज़ एक अस्पष्ट अर्थ है, और हर कार्यान्वयन इस बात पर सहमत है कि यह क्या करता है, क्योंकि RFC में बोली भिन्नताओं के लिए बहुत कम जगह है।
- आप ऐसे मान खोज रहे हैं जो किसी शर्त से मेल खाते हैं, या आप पहले से
सटीक पथ नहीं जानते (“हर ऑब्जेक्ट जिसका
statusfailedहै, जहाँ भी यह दिखाई दे”): JSONPath की ओर रुख करें। यही वह जगह है जहाँ बोली भिन्नताएँ महत्वपूर्ण होने लगती हैं: JSONPath कार्यान्वयन RFC 9535 के अपने उदाहरणों से अधिक भिन्न होते हैं, इसलिए एक लाइब्रेरी के लिए लिखी गई क्वेरी दूसरी में समान व्यवहार की गारंटी नहीं है।
व्यवहार में कहाँ दिखता है
JSON Patch (RFC 6902) ऑपरेशन विशेष रूप से pointers का उपयोग करते हैं; add, remove, replace या move ऑपरेशन में हर "path" एक JSON Pointer है,
क्योंकि एक patch ऑपरेशन डिज़ाइन द्वारा एक सटीक स्थान को लक्षित करता है। JSON
Schema की $ref कुंजी भी pointer वाक्यविन्यास के माध्यम से हल होती है, उसी
कारण से: एक स्कीमा संदर्भ एक परिभाषा की ओर इशारा करता है, न कि उनके एक सेट की ओर।
JSONPath तब दिखाई देता है जब किसी व्यक्ति या उपकरण को इंटरैक्टिव रूप से दस्तावेज़ की क्वेरी करने की आवश्यकता होती है:
किसी बड़े API प्रतिक्रिया को डीबग करना, लॉग से एक फ़ील्ड निकालना,
या एक नियम बनाना जो दिए गए आकार के किसी भी दस्तावेज़ से मेल खाना चाहिए
संबंधित फ़ील्ड ठीक कहाँ बैठता है, इसकी परवाह किए बिना।
दोनों आज़माना
JSON Pointer Evaluator एक दस्तावेज़ के खिलाफ एक pointer को हल करता है और, एक विफल लुकअप पर, रिपोर्ट करता है कि यह कितना आगे पहुँचा और उस बिंदु पर वास्तव में कौन सी कुंजियाँ मौजूद हैं, एक नंगे “नहीं मिला” के बजाय। JSONPath Tester RFC 9535 के दस्तावेजीकृत सबसेट को फ़ंक्शन एक्सटेंशन के साथ चलाता है, और इस साइट के ब्लॉग पर JSONPath चीट शीट में हर चयनक के लिए एक कार्यशील उदाहरण है जो जानने योग्य है। JSON Pointer का उपयोग कैसे करें pointer वाक्यविन्यास को अधिक गहराई से कवर करता है, एस्केप सहित।