सिस्टम डिज़ाइन चीट शीट: एपीआई शैलियाँ - REST, GraphQL, WebSocket, Webhook, RPC/gRPC, SOAP

यह लेखों की एक श्रृंखला की निरंतरता है जिसमें मैं सिस्टम आर्किटेक्चर डिज़ाइन में एक विशिष्ट विषय के मुख्य बिंदुओं को संक्षेप में शामिल करता हूं। पहला लेख यहां पढ़ा जा सकता है

एपीआई आर्किटेक्चर नियमों, प्रोटोकॉल और टूल के सेट को संदर्भित करता है जो यह तय करता है कि सॉफ्टवेयर घटकों को कैसे इंटरैक्ट करना चाहिए। एपीआई का आर्किटेक्चर केवल संचार को सुविधाजनक बनाने के बारे में नहीं है; यह यह सुनिश्चित करने के बारे में भी है कि यह संचार कुशल, सुरक्षित और स्केलेबल है।

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

एपीआई आर्किटेक्चर की विभिन्न शैलियाँ

सबसे आम एपीआई डिज़ाइन शैलियाँ:

1. REST (रिप्रेजेंटेशनल स्टेट ट्रांसफर) सबसे अधिक इस्तेमाल की जाने वाली शैली है जो मानक तरीकों और HTTP प्रोटोकॉल का उपयोग करती है। यह स्टेटलेसनेस, क्लाइंट-सर्वर आर्किटेक्चर और कैशैबिलिटी जैसे सिद्धांतों पर आधारित है। इसका उपयोग अक्सर फ्रंट-एंड क्लाइंट और बैक-एंड सेवाओं के बीच किया जाता है।

   
   

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

   
   

3. वेबसॉकेट एक प्रोटोकॉल है जो टीसीपी पर दो-तरफ़ा संचार की अनुमति देता है। ग्राहक बैक-एंड सिस्टम से वास्तविक समय अपडेट प्राप्त करने के लिए वेब सॉकेट का उपयोग करते हैं।

   
   

4. वेबहुक एक ऐसा तंत्र है जो एक सिस्टम को वास्तविक समय में विशिष्ट घटनाओं के बारे में दूसरे सिस्टम को सूचित करने की अनुमति देता है। यह एक उपयोगकर्ता-परिभाषित HTTP कॉलबैक है।

   
   

5. आरपीसी (जीआरपीसी) एक प्रोटोकॉल है जिसका उपयोग एक सेवा नेटवर्क में किसी अन्य कंप्यूटर पर स्थित सेवा से प्रक्रिया/विधि का अनुरोध करने के लिए कर सकती है। आमतौर पर, इसे कम विलंबता, उच्च गति संचार के लिए डिज़ाइन किया गया है।

   
   

6. SOAP वेब सेवाओं को लागू करने के लिए संरचित जानकारी के आदान-प्रदान के लिए एक प्रोटोकॉल है। यह XML पर निर्भर है और अपनी मजबूती और सुरक्षा सुविधाओं के लिए जाना जाता है, जिसे वर्तमान में एक विरासत प्रोटोकॉल माना जाता है।

आइए प्रत्येक प्रोटोकॉल को उनके सभी पेशेवरों, विपक्षों और उपयोग के मामलों के साथ अलग से देखें।

आराम

REST एक वास्तुशिल्प शैली है जो मानक सम्मेलनों और प्रोटोकॉल का उपयोग करती है, जिससे इसे समझना और लागू करना आसान हो जाता है। इसकी स्टेटलेस प्रकृति और मानक HTTP विधियों का उपयोग इसे वेब-आधारित एपीआई के निर्माण के लिए एक लोकप्रिय विकल्प बनाता है।

जबकि REST लंबे समय से एपीआई के निर्माण के लिए वास्तविक मानक रहा है, ग्राफक्यूएल जैसी अन्य शैलियाँ उभरी हैं, जो डेटा को क्वेरी करने और हेरफेर करने के लिए अलग-अलग प्रतिमान पेश करती हैं।

प्रारूप : XML, JSON, HTML, सादा पाठ

परिवहन प्रोटोकॉल : HTTP/HTTPS

प्रमुख अवधारणाएँ और विशेषताएँ

• संसाधन : REST में, हर चीज़ एक संसाधन है। संसाधन एक वस्तु है जिसमें एक प्रकार, संबद्ध डेटा, अन्य संसाधनों से संबंध और उस पर काम करने वाले तरीकों का एक सेट होता है। संसाधनों की पहचान उनके यूआरआई (आमतौर पर एक यूआरएल) द्वारा की जाती है।

  
  

• सीआरयूडी संचालन : आरईएसटी सेवाएं अक्सर संसाधनों पर सीधे सीआरयूडी (बनाएं, पढ़ें, अपडेट करें, हटाएं) संचालन पर मैप करती हैं।

  
  

• HTTP तरीके : REST सिस्टम मानक HTTP तरीकों का उपयोग करते हैं:

  • प्राप्त करें: एक संसाधन पुनः प्राप्त करें।

  • पोस्ट: एक नया संसाधन बनाएं.

  • पुट/पैच: मौजूदा संसाधन को अपडेट करें।

  • हटाएँ: एक संसाधन हटाएँ।

    
    

• स्थिति कोड : REST API किसी API अनुरोध की सफलता या विफलता को इंगित करने के लिए मानक HTTP स्थिति कोड का उपयोग करते हैं:

  • 2xx - स्वीकार और सफलता
    • 200 - ठीक है
    • 201 - बनाया गया
    • 202 - स्वीकृत
  • 3xx - पुनर्निर्देशन
    • 301 स्थायी रूप से स्थानांतरित
    • 302 - पाया गया
    • 303 - अन्य देखें
  • 4xx - क्लाइंट त्रुटि
    • 400 गलत अनुरोध
    • अनधिकृत 401
    • 403 निषिद्ध
    • 404 नहीं मिला
    • 405 - विधि की अनुमति नहीं है
  • 5xx - सर्वर त्रुटि

    • 500 आंतरिक सर्वर त्रुटि

    • 501 - क्रियान्वित नहीं

    • 502 खराब गेटवे

    • 503 सेवा उपलब्ध नहीं

    • 504 गेटवे समय समाप्त

      
      

• स्टेटलेस : क्लाइंट से सर्वर तक प्रत्येक अनुरोध में अनुरोध को समझने और संसाधित करने के लिए आवश्यक सभी जानकारी होनी चाहिए। सर्वर को अनुरोधों के बीच क्लाइंट की स्थिति के बारे में कुछ भी संग्रहीत नहीं करना चाहिए।

  
  

• क्लाइंट-सर्वर : REST क्लाइंट-सर्वर मॉडल पर आधारित है। क्लाइंट उपयोगकर्ता इंटरफ़ेस और अनुभव के लिए ज़िम्मेदार है, जबकि सर्वर अनुरोधों को संसाधित करने, व्यावसायिक तर्क को संभालने और डेटा संग्रहीत करने के लिए ज़िम्मेदार है।

  
  

• कैश करने योग्य : सर्वर से प्रतिक्रियाएँ क्लाइंट द्वारा कैश की जा सकती हैं। सर्वर को यह बताना होगा कि कोई प्रतिक्रिया कैश करने योग्य है या नहीं।

  
  

• स्तरित प्रणाली : एक ग्राहक आमतौर पर यह नहीं बता सकता है कि यह सीधे अंतिम सर्वर से जुड़ा है या किसी मध्यस्थ से। मध्यस्थ सर्वर लोड संतुलन को सक्षम करके और साझा कैश प्रदान करके सिस्टम स्केलेबिलिटी में सुधार कर सकते हैं।

  
  

• HATEOAS: एप्लिकेशन स्टेट के इंजन के रूप में हाइपरमीडिया एक REST वेब सेवा सिद्धांत है जो ग्राहकों को वेब एप्लिकेशन के साथ बातचीत करने और नेविगेट करने में सक्षम बनाता है जो पूरी तरह से सर्वर द्वारा अपनी प्रतिक्रियाओं में गतिशील रूप से प्रदान किए गए हाइपरमीडिया पर आधारित है, जो ढीली युग्मन और खोज क्षमता को बढ़ावा देता है।

बक्सों का इस्तेमाल करें

• वेब सेवाएँ : कई वेब सेवाएँ REST API के माध्यम से अपनी कार्यक्षमता को उजागर करती हैं, जिससे तृतीय-पक्ष डेवलपर्स को अपनी सेवाओं को एकीकृत और विस्तारित करने की अनुमति मिलती है।

• मोबाइल एप्लिकेशन : मोबाइल एप्लिकेशन अक्सर डेटा लाने और भेजने के लिए REST API का उपयोग करके बैकएंड सर्वर के साथ संचार करते हैं।

• सिंगल पेज एप्लिकेशन (एसपीए) : एसपीए पूर्ण पेज रीफ्रेश की आवश्यकता के बिना सामग्री को गतिशील रूप से लोड करने के लिए आरईएसटी एपीआई का उपयोग करते हैं।

• सिस्टम के बीच एकीकरण: किसी संगठन के भीतर सिस्टम REST API का उपयोग करके डेटा संचार और साझा कर सकते हैं।

उदाहरण

अनुरोध

“/उपयोगकर्ता/42” प्राप्त करें

प्रतिक्रिया

 { "id": 42, "name": "Alex", "links": { "role": "/user/42/role" } }

ग्राफक्यूएल

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

हालाँकि यह सभी परिदृश्यों में REST का प्रतिस्थापन नहीं है, यह कई स्थितियों में एक आकर्षक विकल्प प्रदान करता है, विशेष रूप से जब एप्लिकेशन अधिक नेटवर्क और वितरित हो जाते हैं।

प्रारूप : JSON

परिवहन प्रोटोकॉल : HTTP/HTTPS

प्रमुख अवधारणाएँ और विशेषताएँ

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

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

• सिंगल एंडपॉइंट : REST के विपरीत, जहां आपके पास विभिन्न संसाधनों के लिए कई एंडपॉइंट हो सकते हैं, GraphQL में, आप आमतौर पर एक सिंगल एंडपॉइंट को उजागर करते हैं जो सेवा की क्षमताओं के पूरे सेट को व्यक्त करता है।

• रिज़ॉल्वर : सर्वर साइड पर, रिज़ॉल्वर क्वेरी में वर्णित डेटा एकत्र करते हैं।

• सब्सक्रिप्शन के साथ रीयल-टाइम अपडेट : केवल डेटा क्वेरी करने के अलावा, ग्राफक्यूएल में सब्सक्रिप्शन का उपयोग करके रीयल-टाइम अपडेट के लिए अंतर्निहित समर्थन शामिल है।

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

बक्सों का इस्तेमाल करें

• लचीले फ्रंटेंड : महत्वपूर्ण बैंडविड्थ वाले एप्लिकेशन (विशेष रूप से मोबाइल) के लिए, आप सर्वर से प्राप्त डेटा को कम से कम करना चाहते हैं।

• एग्रीगेटिंग माइक्रोसर्विसेज : यदि आपके पास एकाधिक माइक्रोसर्विसेज हैं तो इन सेवाओं के डेटा को एक एकीकृत एपीआई में एकत्रित करने के लिए एक ग्राफक्यूएल परत पेश की जा सकती है।

• वास्तविक समय अनुप्रयोग : अपनी सदस्यता प्रणाली के साथ, ग्राफक्यूएल उन अनुप्रयोगों के लिए उत्कृष्ट रूप से उपयुक्त हो सकता है जिन्हें वास्तविक समय डेटा की आवश्यकता होती है, जैसे चैट एप्लिकेशन, लाइव स्पोर्ट्स अपडेट इत्यादि।

• संस्करण-मुक्त एपीआई : REST के साथ, परिवर्तन शुरू होने के बाद आपको अक्सर अपने एपीआई को संस्करणबद्ध करने की आवश्यकता होती है। GraphQL के साथ, क्लाइंट केवल आवश्यक डेटा का अनुरोध करते हैं, इसलिए नए फ़ील्ड या प्रकार जोड़ने से ब्रेकिंग परिवर्तन नहीं होते हैं।

उदाहरण

अनुरोध

प्राप्त करें "/graphql?query=user(id:42){नाम भूमिका {आईडी नाम }}"

प्रतिक्रिया

 { "data": { "user": { "id": 42, "name": "Alex", "role": { "id": 1, "name": "admin" } } } }

वेबसॉकेट

WebSockets एकल, लंबे समय तक चलने वाले कनेक्शन पर एक पूर्ण-डुप्लेक्स संचार चैनल प्रदान करता है, जो क्लाइंट और सर्वर के बीच वास्तविक समय डेटा विनिमय की अनुमति देता है। यह इसे इंटरैक्टिव और उच्च-प्रदर्शन वाले वेब अनुप्रयोगों के लिए आदर्श बनाता है।

प्रारूप : बाइनरी

परिवहन प्रोटोकॉल : टीसीपी

प्रमुख अवधारणाएँ और विशेषताएँ

• लगातार कनेक्शन : पारंपरिक अनुरोध-प्रतिक्रिया मॉडल के विपरीत, वेबसॉकेट एक पूर्ण-डुप्लेक्स संचार चैनल प्रदान करता है जो खुला रहता है, जिससे वास्तविक समय डेटा विनिमय की अनुमति मिलती है।

• अपग्रेड हैंडशेक : वेबसॉकेट एक HTTP अनुरोध के रूप में शुरू होता है, जिसे सर्वर समर्थन करने पर वेबसॉकेट कनेक्शन में अपग्रेड किया जाता है। यह `अपग्रेड` हेडर के माध्यम से किया जाता है।

• फ़्रेम : एक बार कनेक्शन स्थापित हो जाने पर, डेटा फ़्रेम के रूप में प्रसारित होता है। इन फ़्रेमों के माध्यम से टेक्स्ट और बाइनरी डेटा दोनों भेजे जा सकते हैं।

• कम विलंबता : वेबसॉकेट प्रत्येक एक्सचेंज के लिए एक नया कनेक्शन खोलने के ओवरहेड के बिना क्लाइंट और सर्वर के बीच सीधे संचार की अनुमति देता है। इससे डेटा का आदान-प्रदान तेजी से होता है।

• द्विदिशात्मक : क्लाइंट और सर्वर दोनों स्वतंत्र रूप से एक दूसरे को संदेश भेज सकते हैं।

• कम ओवरहेड : प्रारंभिक कनेक्शन के बाद, डेटा फ़्रेम को भेजने के लिए कम बाइट्स की आवश्यकता होती है, जिससे बार-बार HTTP कनेक्शन स्थापित करने की तुलना में कम ओवरहेड और बेहतर प्रदर्शन होता है।

• प्रोटोकॉल और एक्सटेंशन : वेबसॉकेट सबप्रोटोकॉल और एक्सटेंशन का समर्थन करते हैं, जो बेस वेबसॉकेट प्रोटोकॉल के शीर्ष पर मानकीकृत और कस्टम प्रोटोकॉल की अनुमति देते हैं।

बक्सों का इस्तेमाल करें

• ऑनलाइन गेमिंग : वास्तविक समय के मल्टीप्लेयर गेम जहां खिलाड़ियों की हरकतें तुरंत अन्य खिलाड़ियों को दिखाई देनी चाहिए।

• सहयोगात्मक उपकरण : Google डॉक्स जैसे एप्लिकेशन, जहां कई उपयोगकर्ता एक साथ किसी दस्तावेज़ को संपादित कर सकते हैं और वास्तविक समय में एक-दूसरे के परिवर्तन देख सकते हैं।

• वित्तीय अनुप्रयोग : स्टॉक ट्रेडिंग प्लेटफ़ॉर्म जहां स्टॉक की कीमतों को वास्तविक समय में अपडेट करने की आवश्यकता होती है।

• सूचनाएं : कोई भी एप्लिकेशन जहां उपयोगकर्ताओं को वास्तविक समय सूचनाएं प्राप्त करने की आवश्यकता होती है, जैसे सोशल मीडिया प्लेटफ़ॉर्म या मैसेजिंग ऐप।

• लाइव फ़ीड्स : समाचार वेबसाइटें या सोशल मीडिया प्लेटफ़ॉर्म जहां नए पोस्ट या अपडेट उपयोगकर्ताओं के लिए लाइव स्ट्रीम किए जाते हैं।

उदाहरण

अनुरोध

“ws://site:8181” प्राप्त करें

प्रतिक्रिया

HTTP/1.1 101 स्विचिंग प्रोटोकॉल

WEbhook

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

प्रारूप : XML, JSON, सादा पाठ

परिवहन प्रोटोकॉल : HTTP/HTTPS

प्रमुख अवधारणाएँ और विशेषताएँ

• ईवेंट-संचालित : वेबहुक का उपयोग आम तौर पर यह दर्शाने के लिए किया जाता है कि कोई ईवेंट घटित हुआ है। नियमित अंतराल पर डेटा का अनुरोध करने के बजाय, वेबहुक पारंपरिक अनुरोध-प्रतिक्रिया मॉडल को उल्टा करते हुए डेटा प्रदान करते हैं।

• कॉलबैक तंत्र : वेबहुक अनिवार्य रूप से एक उपयोगकर्ता-परिभाषित कॉलबैक तंत्र है। जब कोई विशिष्ट घटना घटती है, तो स्रोत साइट लक्ष्य साइट द्वारा प्रदान किए गए यूआरआई पर एक HTTP कॉलबैक करती है, जो तब एक विशिष्ट कार्रवाई करेगी।

• पेलोड : जब वेबहुक चालू हो जाता है, तो स्रोत साइट लक्ष्य साइट पर डेटा (पेलोड) भेजेगी। यह डेटा आमतौर पर JSON या XML के रूप में होता है।

• रीयल-टाइम : वेबहुक एप्लिकेशन को रीयल-टाइम डेटा प्राप्त करने की अनुमति देता है, जिससे वे अत्यधिक प्रतिक्रियाशील हो जाते हैं।

• अनुकूलन योग्य : उपयोगकर्ता या डेवलपर आम तौर पर परिभाषित कर सकते हैं कि वे किन विशिष्ट घटनाओं के बारे में सूचित होना चाहते हैं।

• सुरक्षा : चूंकि वेबहुक में उपयोगकर्ता द्वारा परिभाषित HTTP एंडपॉइंट पर कॉलबैक करना शामिल है, इसलिए वे सुरक्षा चुनौतियां पैदा कर सकते हैं। यह सुनिश्चित करना महत्वपूर्ण है कि समापन बिंदु सुरक्षित है, डेटा मान्य है, और संभवतः एन्क्रिप्ट किया गया है।

बक्सों का इस्तेमाल करें

• सतत एकीकरण और परिनियोजन (सीआई/सीडी) : जब कोड को पुश किया जाता है, या पुल अनुरोध को मर्ज किया जाता है, तो निर्माण और परिनियोजन को ट्रिगर किया जाता है।

• सामग्री प्रबंधन प्रणाली (सीएमएस) : सामग्री अद्यतन, प्रकाशित या हटाए जाने पर डाउनस्ट्रीम सिस्टम को सूचित करना।

• भुगतान गेटवे : ई-कॉमर्स प्लेटफ़ॉर्म को लेनदेन के परिणामों, जैसे सफल भुगतान, विफल लेनदेन या रिफंड के बारे में सूचित करना।

• सोशल मीडिया एकीकरण : सोशल मीडिया प्लेटफॉर्म पर नए पोस्ट, उल्लेख या अन्य प्रासंगिक घटनाओं के बारे में सूचनाएं प्राप्त करना।

• IoT (इंटरनेट ऑफ थिंग्स) : डिवाइस या सेंसर विशिष्ट घटनाओं या डेटा रीडिंग के बारे में अन्य सिस्टम या सेवाओं को सूचित करने के लिए वेबहुक ट्रिगर कर सकते हैं।

उदाहरण

अनुरोध

“ https://external-site/webhooks?url=http://site/service-h/api&name=name ” प्राप्त करें

प्रतिक्रिया

 { "webhook_id": 12 }

आरपीसी और जीआरपीसी

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

GRPC (Google RPC) RPC के शीर्ष पर निर्मित एक आधुनिक, ओपन-सोर्स फ्रेमवर्क है जो परिवहन के लिए HTTP/2 और इंटरफ़ेस विवरण भाषा के रूप में प्रोटोकॉल बफ़र्स का उपयोग करता है, जो कुशल और मजबूत संचार की सुविधा के लिए प्रमाणीकरण, लोड संतुलन और बहुत कुछ जैसी सुविधाएँ प्रदान करता है। माइक्रोसर्विसेज के बीच।

आरपीसी

प्रारूप : JSON, XML, प्रोटोबफ़, थ्रिफ्ट, फ़्लैटबफ़र्स

परिवहन प्रोटोकॉल : विभिन्न

प्रमुख अवधारणाएँ और विशेषताएँ

• परिभाषा : आरपीसी एक प्रोग्राम को किसी प्रक्रिया (सबरूटीन) को किसी अन्य एड्रेस स्पेस (आमतौर पर साझा नेटवर्क पर किसी अन्य कंप्यूटर पर) में निष्पादित करने की अनुमति देता है। यह कॉल करने वाले की मशीन से भिन्न मशीन पर निष्पादित फ़ंक्शन को कॉल करने जैसा है।

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

• डिफ़ॉल्ट रूप से सिंक्रोनस : पारंपरिक आरपीसी कॉल ब्लॉक हो रही हैं, जिसका अर्थ है कि क्लाइंट सर्वर को एक अनुरोध भेजता है और सर्वर से प्रतिक्रिया की प्रतीक्षा में ब्लॉक हो जाता है।

• भाषा तटस्थ : कई आरपीसी सिस्टम विभिन्न क्लाइंट और सर्वर कार्यान्वयन को संचार करने की अनुमति देते हैं, भले ही वे जिस भाषा में लिखे गए हों।

• टाइट कपलिंग : आरपीसी को अक्सर क्लाइंट और सर्वर को कॉल की जाने वाली प्रक्रिया, उसके पैरामीटर और उसके रिटर्न प्रकार को जानने की आवश्यकता होती है।

बक्सों का इस्तेमाल करें

• वितरित सिस्टम : आरपीसी का उपयोग आमतौर पर वितरित सिस्टम में किया जाता है जहां सिस्टम के हिस्से विभिन्न मशीनों या नेटवर्क में फैले होते हैं लेकिन उन्हें इस तरह संचार करने की आवश्यकता होती है जैसे कि वे स्थानीय हों।

• नेटवर्क फाइल सिस्टम : एनएफएस (नेटवर्क फाइल सिस्टम) दूर से फाइल संचालन करने वाले आरपीसी का एक उदाहरण है।

उदाहरण

अनुरोध

 { "method": "addUser", "params": [ "Alex" ] }

प्रतिक्रिया

 { "id": 42, "name": "Alex", "error": null }

जीआरपीसी

प्रारूप : प्रोटोबफ़

ट्रांसपोर्ट प्रोटोकॉल : HTTP/2

प्रमुख अवधारणाएँ और विशेषताएँ

• परिभाषा : gRPC Google द्वारा विकसित एक ओपन-सोर्स RPC फ्रेमवर्क है। यह परिवहन के लिए HTTP/2, इंटरफ़ेस विवरण भाषा के रूप में प्रोटोकॉल बफ़र्स (प्रोटोबफ़) का उपयोग करता है, और प्रमाणीकरण, लोड संतुलन सुविधाएँ और बहुत कुछ प्रदान करता है।

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

• प्रदर्शन : जीआरपीसी को कम विलंबता और उच्च थ्रूपुट संचार के लिए डिज़ाइन किया गया है। HTTP/2 एक ही कनेक्शन पर कई कॉलों को मल्टीप्लेक्स करने की अनुमति देता है और ओवरहेड को कम करता है।

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

• समय सीमा/समय सीमा : जीआरपीसी ग्राहकों को यह निर्दिष्ट करने की अनुमति देती है कि वे आरपीसी के पूरा होने के लिए कितने समय तक इंतजार करेंगे। सर्वर इसकी जांच कर सकता है और निर्णय ले सकता है कि क्या ऑपरेशन को पूरा करना है या रद्द करना है यदि इसमें बहुत अधिक समय लगने की संभावना है।

• प्लग करने योग्य : जीआरपीसी को प्लग करने योग्य प्रमाणीकरण, लोड संतुलन, पुनः प्रयास आदि का समर्थन करने के लिए डिज़ाइन किया गया है।

• भाषा तटस्थ : आरपीसी की तरह, जीआरपीसी भाषा अज्ञेयवादी है। हालाँकि, प्रोटोबफ़ और जीआरपीसी टूलिंग के साथ, कई भाषाओं में क्लाइंट और सर्वर कोड बनाना आसान है।

बक्सों का इस्तेमाल करें

• माइक्रोसर्विसेज : जीआरपीसी का उपयोग आमतौर पर इसकी प्रदर्शन विशेषताओं और सेवा अनुबंधों को आसानी से परिभाषित करने की क्षमता के कारण माइक्रोसर्विसेज आर्किटेक्चर में किया जाता है।

• वास्तविक समय अनुप्रयोग : स्ट्रीमिंग के लिए इसके समर्थन को देखते हुए, जीआरपीसी वास्तविक समय अनुप्रयोगों के लिए उपयुक्त है जहां सर्वर वास्तविक समय में ग्राहकों को डेटा भेजते हैं।

• मोबाइल ग्राहक : जीआरपीसी के प्रदर्शन लाभ और स्ट्रीमिंग क्षमताएं इसे बैकएंड सेवाओं के साथ संचार करने वाले मोबाइल ग्राहकों के लिए उपयुक्त बनाती हैं।

उदाहरण

 message User { int id = 1 string name = 2 } service UserService { rpc AddUser(User) returns (User); }

साबुन

SOAP , जो सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल के लिए है, कंप्यूटर नेटवर्क में वेब सेवाओं को लागू करने के लिए संरचित जानकारी के आदान-प्रदान के लिए एक प्रोटोकॉल है। यह एक XML-आधारित प्रोटोकॉल है जो अलग-अलग ऑपरेटिंग सिस्टम पर चलने वाले प्रोग्रामों को एक-दूसरे के साथ संचार करने की अनुमति देता है।

प्रारूप : एक्सएमएल

ट्रांसपोर्ट प्रोटोकॉल : HTTP/HTTPS, JMS, SMTP, और बहुत कुछ

प्रमुख अवधारणाएँ और विशेषताएँ

• XML-आधारित : SOAP संदेश XML में स्वरूपित होते हैं और इनमें निम्नलिखित तत्व होते हैं:

  • लिफ़ाफ़ा : SOAP संदेश का मूल तत्व जो XML दस्तावेज़ को SOAP संदेश के रूप में परिभाषित करता है।

  
  

  • हेडर : संदेश को संसाधित करने में उपयोग किए जाने वाले संदेश की कोई भी वैकल्पिक विशेषताएँ शामिल होती हैं, या तो किसी मध्यस्थ बिंदु पर या अंतिम अंत-बिंदु पर।

  
  

  • मुख्य भाग : इसमें भेजे जा रहे संदेश सहित XML डेटा शामिल है।

  
  

  • दोष : एक वैकल्पिक दोष तत्व जो संदेश को संसाधित करते समय त्रुटियों के बारे में जानकारी प्रदान करता है।

    
    

• तटस्थता : SOAP का उपयोग किसी भी प्रोग्रामिंग मॉडल के साथ किया जा सकता है और यह किसी विशिष्ट मॉडल से बंधा नहीं है।

• इंडिपेंडेंस : यह किसी भी ऑपरेटिंग सिस्टम और किसी भी भाषा में चल सकता है।

• स्टेटलेस : क्लाइंट से सर्वर तक प्रत्येक अनुरोध में अनुरोध को समझने और संसाधित करने के लिए आवश्यक सभी जानकारी होनी चाहिए।

• अंतर्निहित त्रुटि प्रबंधन : SOAP संदेश में दोष तत्व का उपयोग त्रुटि रिपोर्टिंग के लिए किया जाता है।

• मानकीकृत : अच्छी तरह से परिभाषित मानकों के आधार पर संचालित होता है, जिसमें स्वयं SOAP विनिर्देश, साथ ही संदेश वितरण सुनिश्चित करने के लिए WS-विश्वसनीय मैसेजिंग, संदेश सुरक्षा के लिए WS-सुरक्षा और बहुत कुछ जैसे संबंधित मानक शामिल हैं।

बक्सों का इस्तेमाल करें

• एंटरप्राइज़ अनुप्रयोग : SOAP का उपयोग अक्सर इसकी मजबूती, विस्तारशीलता और फ़ायरवॉल और प्रॉक्सी को पार करने की क्षमता के कारण एंटरप्राइज़ सेटिंग्स में किया जाता है।

• वेब सेवाएँ : कई वेब सेवाएँ, विशेषकर पुरानी सेवाएँ, SOAP का उपयोग करती हैं। इसमें Microsoft और IBM जैसी प्रमुख कंपनियों द्वारा दी जाने वाली सेवाएँ शामिल हैं।

• वित्तीय लेनदेन : SOAP की अंतर्निहित सुरक्षा और विस्तारशीलता इसे वित्तीय लेनदेन के लिए एक अच्छा विकल्प बनाती है, जहां डेटा अखंडता और सुरक्षा सर्वोपरि है।

• दूरसंचार : दूरसंचार कंपनियां बिलिंग जैसी प्रक्रियाओं के लिए SOAP का उपयोग कर सकती हैं, जहां विभिन्न प्रणालियों को विश्वसनीय रूप से संचार करना होगा।

उदाहरण

अनुरोध

 <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserRequest> <m:Name>Alex</m:Name> </m:AddUserRequest> </soap:Body> </soap:Envelope>

प्रतिक्रिया

 <?xml version="1.0"?> <soap:Envelope> <soap:Body> <m:AddUserResponse> <m:Id>42</m:Id> <m:Name>Alex</m:Name> </m:AddUserResponse> </soap:Body> </soap:Envelope>

निष्कर्ष

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