JSON-RPC क्या है? संदेश, विधियाँ, और त्रुटि प्रबंधन

JSON-RPC क्या है?

JSON-RPC एक हल्का, स्टेटलेस रिमोट प्रोसीजर कॉल प्रोटोकॉल है जो विधि कॉल, परिणाम और त्रुटियों को JSON ऑब्जेक्ट्स के रूप में दर्शाता है। संस्करण 2.0 संदेश सदस्यों और प्रसंस्करण नियमों को परिभाषित करता है लेकिन HTTP या किसी अन्य विशिष्ट परिवहन की आवश्यकता नहीं होती। एक क्लाइंट एक विधि का नाम रखता है, वैकल्पिक रूप से संरचित पैरामीटर प्रदान करता है, और एक ID का उपयोग प्रतिक्रिया को उसके अनुरोध के साथ समन्वय करने के लिए करता है।

लाभकारी परिभाषा में तंत्र और इसकी सीमा शामिल होती है। JSON-RPC एक विनिमय के एक विशिष्ट हिस्से को प्रभावित करता है, जबकि समवर्ती जिम्मेदारियाँ HTTP, ब्राउज़र, चयनित परिवहन, एप्लिकेशन, या सर्वर के डेटा मॉडल के साथ रहती हैं। उन परतों को अलग रखना त्रुटि रिपोर्ट को पुन: उत्पन्न करने योग्य बनाता है और एक कॉन्फ़िगरेशन परिवर्तन को पहुँच-नियंत्रण निर्णय के रूप में गलत होने से रोकता है।

API डेवलपर्स के लिए, पहला सवाल यह है कि मूल्य या व्यवहार कौन बनाता है। अगला सवाल यह है कि इसे कौन व्याख्या करता है। अंतिम सवाल यह है कि कौन-सी प्रेक्षणीय परिणाम यह साबित करता है कि व्याख्या सफल रही। ये तीन उत्तर एक शब्दावली को एक परीक्षण योग्य इंटरफ़ेस अनुबंध में बदल देते हैं।

कैसे JSON-RPC संदेश एक वार्ता बनाते हैं

एक अनुरोध ऑब्जेक्ट में jsonrpc 2.0 पर सेट है, एक विधि स्ट्रिंग, वैकल्पिक पैरामीटर्स, और आमतौर पर एक ID होती है। पैरामीटर्स को स्थिति तर्कों के लिए एक सरणी या नामित तर्कों के लिए एक ऑब्जेक्ट होना चाहिए। नामित पैरामेटर्स आकस्मिक निर्भरता को क्रम में कम करते हैं, लेकिन उनके नाम को सर्वर अनुबंध के साथ ठीक से मेल खाना चाहिए।

एक सफल प्रतिक्रिया अनुरोध ID को दोहराती है और एक परिणाम सदस्य को शामिल करती है। एक असफल प्रतिक्रिया ID को दोहराती है और एक त्रुटि ऑब्जेक्ट को संख्यात्मक कोड और संदेश के साथ, अतिरिक्त डेटा के साथ शामिल करती है। परिणाम और त्रुटि वैकल्पिक हैं; एक प्रतिक्रिया को दोनों परिणामों का दावा नहीं करना चाहिए।

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

एक बैच एक JSON सरणी है जिसमें कई अनुरोध या सूचना ऑब्जेक्ट होते हैं। सर्वर उन्हें अपने आदेश में संसाधित कर सकता है, और प्रतिक्रिया का आदेश अनुरोध के आदेश से मेल खाने की आवश्यकता नहीं है। इसलिए ग्राहक बैच परिणामों को ID द्वारा मेल करते हैं न कि सरणी की स्थिति द्वारा।

एक JSON-RPC 2.0 ऑब्जेक्ट में सदस्य

निम्नलिखित शर्तें उन घटकों को अलग करती हैं जिन्हें अक्सर एक लेबल में समकक्ष बनाया जाता है। उन्हें प्रतिभागियों के बीच इंटरफेस के रूप में पढ़ें, ना कि नेटवर्क ट्रेस में सजावट के रूप में।

वेब डेटा संग्रह में JSON-RPC का महत्व

JSON-RPC उन बाइट्स को बदल सकता है जो आते हैं, उन बाइट्स को कैसे व्याख्यायित किया जाता है, या क्या ब्राउज़र कोड परिणाम को देख सकता है। एक संग्रह कार्यप्रवाह को उपकरण बदलने से पहले उस प्रभाव को खोजने चाहिए। अनुरोधित URL, अंतिम URL, प्रतिक्रिया स्थिति, प्रतिनिधित्व प्रकार, प्रासंगिक प्रोटोकॉल क्षेत्रों, और एक अपेक्षित सामग्री मार्कर को रिकॉर्ड करें। वह संकुचित रिकॉर्ड एक सही पृष्ठ को एक पहुँच संदेश, सहमति स्क्रीन, पुनर्निर्देश लक्ष्य, खाली एप्लिकेशन शेल, या असंगत एन्कोडिंग से अलग करता है।

प्रत्यक्ष HTTP सबसे सरल अधिग्रहण पथ है जब आवश्यक डेटा एक खुले सर्वर-रेंडर्ड प्रतिक्रिया में मौजूद हो। जब अनुमोदित सामग्री JavaScript निष्पादन, ब्राउज़र-प्रबंधित राज्य, नेविगेशन, या ब्राउज़र सुरक्षा नीति पर निर्भर करती है, तो एक ब्राउज़र प्रासंगिक हो जाता है। दोनों पथों को एक समान दिखने के लिए मजबूर नहीं किया जाना चाहिए: ब्राउज़र कुकीज़, संकुचन, पुनर्निर्देश, CORS, और प्लेटफ़ॉर्म नियमों के अनुसार संग्रहण का प्रबंधन करते हैं, जबकि एक प्रत्यक्ष ग्राहक एक अलग सेट के डिफ़ॉल्ट्स को उजागर करता है।

सत्र निरंतरता तब महत्वपूर्ण होती है जब एक प्रतिक्रिया अगले अनुरोध के लिए राज्य स्थापित करती है। एक अधिकृत अनुक्रम को एक सीमित क्लाइंट संदर्भ के भीतर रखना, आवश्यक क्षेत्र और नेटवर्क मूल को संरक्षित करना, और असंबंधित नौकरियों से स्थिति को मिलाना बचें। एक प्रॉक्सी नेटवर्क मूल को बदलता है; यह हेडर को पुन: उत्पन्न नहीं करता है, प्रतिनिधित्व को डिकोड नहीं करता, स्क्रिप्ट निष्पादित नहीं करता, या प्रतिबंधित सामग्री तक पहुँच देने की अनुमति नहीं देता।

प्रतिनिधित्व सत्यापन के बाद ही पार्सिंग शुरू होती है। क्षेत्रों को निकालने से पहले अंतिम होस्ट, कैनोनिकल पहचान जहाँ उपलब्ध हो, मीडिया प्रकार, डिकोडिंग स्थिति, और आवश्यक व्यावसायिक मार्कर की पुष्टि करें। यह क्रम एक पार्सर को एक त्रुटि दस्तावेज़ को तकनीकी रूप से सफल दिखने वाले खाली रिकॉर्ड में बदलने से रोकता है।

मध्यवर्तियों को स्पष्ट ध्यान की आवश्यकता है। एक सामग्री वितरण नेटवर्क एक एनकोड किए गए विकल्प का चयन कर सकता है, एक गेटवे OPTIONS का उत्तर दे सकता है, एक कैश एक बातचीत की गई प्रतिक्रिया का पुन: उपयोग कर सकता है, और एक अनुप्रयोग सर्वर कुकीज़ या प्रमाणीकरण क्षेत्रों को सेट कर सकता है। केवल अंतिम पृष्ठ आउटपुट के साथ अनुप्रयोग कोड की तुलना करना उस परत को छोड़ देता है जिसने निर्णय लिया हो सकता है।

स्क्रेपलेस यूनिवर्सल स्क्रैपिंग एपीआई उस समय प्रासंगिक है जब एक टीम को अनुमत सार्वजनिक सामग्री की प्रबंधित पुनर्प्राप्ति की आवश्यकता होती है, जिसमें जावास्क्रिप्ट-जनित पृष्ठ शामिल हैं। अधिग्रहण अनुबंध को फिर भी लक्ष्य, अनुमत क्षेत्रों, अपेक्षित प्रतिनिधित्व, स्वीकृति मार्कर, और रोकने की शर्तों को परिभाषित करना चाहिए। उत्पाद क्षमता स्रोत शर्तों, गोपनीयता समीक्षा, या अनुप्रयोग-स्तरीय सत्यापन को प्रतिस्थापित नहीं करती है।

जब JSON-RPC उपयुक्त होता है

JSON-RPC को एक आर्किटेक्चर में स्थान मिलता है जब यह एक ठोस उत्पाद व्यवहार, संगतता आवश्यकता, या नैदानिक निर्णय को बदलता है। ये उपयोग के मामले पहले काम का वर्णन करते हैं और दूसरी बात प्रोटोकॉल विशेषता का।

JSON-RPC की तुलना REST-शैली HTTP और gRPC से

JSON-RPC API को विधि आवाहन पर केंद्रित करता है, जबकि REST-शैली HTTP इसे संसाधनों, प्रतिनिधित्व, और मानक विधि व्याकरण पर केंद्रित करता है। gRPC भी विधियों का मॉडल करता है, लेकिन एक स्कीमा टूलचेन और एक बाइनरी-उन्मुख परिवहन स्टैक जोड़ता है। JSON-RPC आकर्षक है जब एक संक्षिप्त विधि लिफाफा महत्वपूर्ण होता है और परिवहन को एक अलग विकल्प बने रहना चाहिए।

एक तुलना केवल तभी उपयोगी होती है जब यह परत सीमाओं को संरक्षित करती है। दो तंत्र एक अनुरोध में सह-अस्तित्व में हो सकते हैं, और एक को बदलना दूसरे को स्वचालित रूप से नहीं बदलता है। चुनी गई व्यवहार को इनपुट्स, प्रेक्षणीय आउटपुट, विफलता स्थिति, और स्वामित्व के संदर्भ में दस्तावेज़ करें।

JSON-RPC गलतियाँ जो अस्पष्ट परिणामों का कारण बनती हैं

• महत्वपूर्ण लेखनों के लिए सूचनाओं का उपयोग। एक सूचना का कोई उत्तर नहीं होता, इसलिए कॉलर यह नहीं जान सकता कि क्या सत्यापन या निष्पादन विफल हुआ।
• स्थिति के अनुसार बैच प्रतिक्रियाओं का मिलान करना। विशेषण किसी भी क्रम में प्रतिक्रियाओं की अनुमति देता है। प्रत्येक परिणाम को अनुरोध आईडी से मिलान करें।
• कॉल्स सक्रिय रहते समय आईडी का पुन: उपयोग करना। नकल सक्रिय आईडी सह correlaids को अस्पष्ट बनाते हैं, विशेष रूप से एक लगातार कनेक्शन पर।
• HTTP स्थिति को विधि परिणाम के रूप में मानते हुए। जब JSON-RPC HTTP पर चलता है, तो परिवहन स्थिति और JSON-RPC परिणाम विभिन्न परतों का वर्णन करते हैं। दोनों की जांच करें।
• विधि योजनाओं को निहित छोड़ना। लिफाफा प्रोटोकॉल सदस्यों को परिभाषित करता है, न कि प्रत्येक आवेदन विधि के लिए प्रकार और नियम। एक अलग विधि अनुबंध प्रकाशित करें।
• आंतरिक अपवाद पाठ को वापस करना। त्रुटि डेटा स्टैक विवरण या रहस्यों को उजागर कर सकता है। असफलताओं को स्थिर सार्वजनिक कोड और अनुमोदित निदान क्षेत्रों से मानचित्रित करें।

अधिकांश असफलताएँ स्वचालित रूप से पुस्तकालय या ब्राउज़र द्वारा किए गए कार्यों के बारे में धारणाएँ हटाने के बाद निदान करना आसान हो जाती हैं। एक न्यूनतम ट्रेस कैप्चर करें, रहस्यों को हटा दें, और एक समय में एक नियंत्रित चर बदलें। लक्ष्य वापस की गई प्रतिनिधित्व की एक स्थिर व्याख्या है, न कि अपरिवर्तित शीर्षक समायोजनों का एक संग्रह।

एक JSON-RPC समीक्षा अनुक्रम।

यह अनुक्रम प्रक्षिप्ति से पहले एक डिज़ाइन समीक्षा के रूप में और व्यवहार परिवर्तन के बाद उत्पादन निदान के रूप में कार्य करता है। यह प्रोटोकॉल साक्ष्य को आवेदन परिणाम से जोड़े रखता है।

1. प्रत्येक विधि का सूची बनाएं और यह तय करें कि उसके पैरामीटर अवस्थाक्रमी या नामित हैं; एक API के भीतर आकस्मिक रूप से सौंदर्यशास्त्र को न मिलाएं।
2. हैंडलर लागू करने से पहले प्रत्येक विधि के लिए परिणाम स्कीमा और सार्वजनिक त्रुटि कोड परिभाषित करें।
3. एक पहचान उत्पन्न करने का नियम चुनें जो सक्रिय कॉल के बीच अद्वितीय बना रहता है और प्रत्येक क्लाइंट भाषा में कार्य करता है।
4. लॉग और परीक्षण में परिवहन असफलताओं, खराब JSON, अमान्य JSON-RPC वस्तुओं, विधि त्रुटियों, और सफल परिणामों को अलग करें।
5. जवाब की प्रत्याशा किए बिना सूचनाओं का परीक्षण करें, जिसमें बैच के अंदर रखी गई सूचनाएँ शामिल हैं।
6. परीक्षण में बैच प्रतिक्रिया क्रम को शफल करें ताकि साबित हो सके कि क्लाइंट पहचान द्वारा न corr जब कि पिछले सूची अनुक्रम द्वारा।
7. JSON-RPC स्वयं उन्हें परिभाषित नहीं करता है, इसलिए प्रमाणीकरण, प्राधिकरण, संदेश-आकार सीमाएँ, और परिवहन रूपरेखा का दस्तावेजीकरण करें।

समीक्षा समाप्त करें छोटे स्वीकृत नमूने और एक अस्वीकृत नमूना को समान लाल रेखा नियमों के साथ सहेजें। भविष्य के परिवर्तन ज्ञात पृष्ठ पहचान, अपेक्षित क्षेत्रों और डिक्रिप्टेड सामग्री के खिलाफ भी तुलना की जा सकती है, न कि केवल मेमोरी या स्क्रीनशॉट के खिलाफ।

JSON लिफाफे के बाहर सुरक्षा सीमाएँ।

JSON-RPC कॉलर्स का प्रमाणीकरण नहीं करता है, ट्रैफ़िक को एन्क्रिप्ट नहीं करता है, संदेश का आकार सीमित नहीं करता है, या विधि को अधिकृत नहीं करता है। उन नियंत्रणों का संबंध चयनित परिवहन और अनुप्रयोग से है। एक WebSocket परिनियोजन, एक HTTP परिनियोजन, और एक स्थानीय स्ट्रीम समान JSON-RPC वस्तुओं का उपयोग कर सकते हैं जबकि उनकी विभिन्न खतरे मॉडल हैं।

विधि नाम और पैरामीटर अविश्वसनीय इनपुट हैं। अनुमति सूची के खिलाफ विधि की पुष्टि करें, विधि स्कीमा के खिलाफ पैरामीटर की पुष्टि करें, और कॉलर पहचान स्थापित होने के बाद प्राधिकरण लागू करें। एक व्याकरणिक रूप से मान्य JSON-RPC अनुरोध संचालन चलाने की अनुमति नहीं है।

त्रुटि प्रतिक्रियाएँ ग्राहकों को कार्य करने में मदद करनी चाहिए बिना कार्यान्वयन विवरण उजागर किए। स्थिर सार्वजनिक कोड, एक संक्षिप्त संदेश, और सीमित संरचित डेटा कच्ची अपवादों की तुलना में निगरानी करना आसान है। लॉग एक आंतरिक संबंध मूल्य बनाए रख सकते हैं बिना पूर्ण संवेदनशील पैरामीटर वस्तुओं की कॉपी के।

JSON-RPC को परिभाषित करने वाले मानक।

JSON-RPC 2.0 विनिर्देश। यह अनुरोधों, प्रतिक्रियाओं, सूचनाओं, और बैचों को परिभाषित करता है। यह प्राथमिक स्रोत इस लेख में उपयोग की गई शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार को चयनित क्लाइंट और परिनियोजन में अभी भी देखा जाना चाहिए।

JSON डेटा विनिमय मानक। यह प्रोटोकॉल द्वारा ले जाए जाने वाले JSON संवाद को परिभाषित करता है। यह प्राथमिक स्रोत इस लेख में उपयोग की गई शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार को चयनित क्लाइंट और परिनियोजन में अभी भी देखा जाना चाहिए।

OpenRPC विनिर्देश। यह JSON-RPC एपीआई के लिए मशीन-पठनीय विवरण प्रारूप प्रदान करता है। यह प्राथमिक स्रोत इस लेख में उपयोग की गई शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार को चयनित क्लाइंट और परिनियोजन में अभी भी देखा जाना चाहिए।

WebSocket प्रोटोकॉल। यह JSON-RPC संदेशों के लिए एक संभव निरंतर परिवहन है। यह प्राथमिक स्रोत इस लेख में उपयोग की गई शब्दावली और सीमा को ठीक करता है, जबकि कार्यान्वयन व्यवहार को चयनित क्लाइंट और परिनियोजन में अभी भी देखा जाना चाहिए।

JSON-RPC निष्कर्ष।

JSON-RPC एक छोटा विधि-काल प्रोटोकॉल है, एक संपूर्ण एपीआई प्लेटफार्म नहीं; इसकी सरलता सबसे अच्छी होती है जब टीमें स्पष्ट रूप से विधि योजनाओं, परिवहन व्यवहार, सुरक्षा और लिफाफे के चारों ओर अवलोकन को परिभाषित करती हैं।

उस नियम को एक स्वीकृति परीक्षण में डालें। बताएं कि कौन सा प्रतिभागी संकेत भेजता है, कौन सा प्रतिभागी इसे समझता है, कौन से मध्यवर्ती पथ को बदल सकते हैं, और कौन सा सामग्री चिह्न सफलता को प्रमाणित करता है। इससे JSON-RPC एक अवलोकनीय प्रणाली का हिस्सा बनता है न कि एक लेबल जो विफलता के बाद संलग्न किया गया हो।

संदर्भ

• स्क्रेपलेस यूनिवर्सल स्क्रैपिंग एपीआई दस्तावेज़
• स्क्रेपलेस यूनिवर्सल स्क्रैपिंग एपीआई उत्पाद अवलोकन
• हेडर्स, कुकीज़, सेशन्स और प्रतिनिधित्व मान्यता के लिए स्क्रेपलेस गाइड
• स्क्रेपलेस गिटहब पर