यह लेखों की एक श्रृंखला की निरंतरता है जिसमें मैं सिस्टम आर्किटेक्चर डिज़ाइन में एक विशिष्ट विषय के मुख्य बिंदुओं को संक्षेप में शामिल करता हूं। पहला लेख पढ़ा जा सकता है यहां एपीआई आर्किटेक्चर नियमों, प्रोटोकॉल और टूल के सेट को संदर्भित करता है जो यह तय करता है कि सॉफ्टवेयर घटकों को कैसे इंटरैक्ट करना चाहिए। एपीआई का आर्किटेक्चर केवल संचार को सुविधाजनक बनाने के बारे में नहीं है; यह यह सुनिश्चित करने के बारे में भी है कि यह संचार कुशल, सुरक्षित और स्केलेबल है। एक अच्छी तरह से डिज़ाइन किया गया एपीआई आर्किटेक्चर एक सिस्टम के प्रदर्शन को महत्वपूर्ण रूप से बढ़ा सकता है, जबकि एक खराब डिज़ाइन वाला आर्किटेक्चर बाधाओं, सुरक्षा कमजोरियों और रखरखाव के बुरे सपने का कारण बन सकता है। एपीआई आर्किटेक्चर की विभिन्न शैलियाँ सबसे आम एपीआई डिज़ाइन शैलियाँ: (रिप्रेजेंटेशनल स्टेट ट्रांसफर) सबसे अधिक इस्तेमाल की जाने वाली शैली है जो मानक तरीकों और HTTP प्रोटोकॉल का उपयोग करती है। यह स्टेटलेसनेस, क्लाइंट-सर्वर आर्किटेक्चर और कैशैबिलिटी जैसे सिद्धांतों पर आधारित है। इसका उपयोग अक्सर फ्रंट-एंड क्लाइंट और बैक-एंड सेवाओं के बीच किया जाता है। REST एपीआई के लिए एक क्वेरी भाषा है। REST के विपरीत, जो प्रत्येक संसाधन के लिए अंतिम बिंदुओं के एक निश्चित सेट को उजागर करता है, GraphQL ग्राहकों को उनके लिए आवश्यक डेटा का अनुरोध करने की अनुमति देता है, जिससे ओवर-फ़ेचिंग कम हो जाती है। ग्राफक्यूएल एक प्रोटोकॉल है जो टीसीपी पर दो-तरफ़ा संचार की अनुमति देता है। ग्राहक बैक-एंड सिस्टम से वास्तविक समय अपडेट प्राप्त करने के लिए वेब सॉकेट का उपयोग करते हैं। वेबसॉकेट एक ऐसा तंत्र है जो एक सिस्टम को वास्तविक समय में विशिष्ट घटनाओं के बारे में दूसरे सिस्टम को सूचित करने की अनुमति देता है। यह एक उपयोगकर्ता-परिभाषित HTTP कॉलबैक है। वेबहुक एक प्रोटोकॉल है जिसका उपयोग एक सेवा नेटवर्क में किसी अन्य कंप्यूटर पर स्थित सेवा से प्रक्रिया/विधि का अनुरोध करने के लिए कर सकती है। आमतौर पर, इसे कम विलंबता, उच्च गति संचार के लिए डिज़ाइन किया गया है। आरपीसी (जीआरपीसी) वेब सेवाओं को लागू करने के लिए संरचित जानकारी के आदान-प्रदान के लिए एक प्रोटोकॉल है। यह XML पर निर्भर है और अपनी मजबूती और सुरक्षा सुविधाओं के लिए जाना जाता है, जिसे वर्तमान में एक विरासत प्रोटोकॉल माना जाता है। SOAP आइए प्रत्येक प्रोटोकॉल को उनके सभी पेशेवरों, विपक्षों और उपयोग के मामलों के साथ अलग से देखें। आराम एक वास्तुशिल्प शैली है जो मानक सम्मेलनों और प्रोटोकॉल का उपयोग करती है, जिससे इसे समझना और लागू करना आसान हो जाता है। इसकी स्टेटलेस प्रकृति और मानक HTTP विधियों का उपयोग इसे वेब-आधारित एपीआई के निर्माण के लिए एक लोकप्रिय विकल्प बनाता है। REST जबकि REST लंबे समय से एपीआई के निर्माण के लिए वास्तविक मानक रहा है, ग्राफक्यूएल जैसी अन्य शैलियाँ उभरी हैं, जो डेटा को क्वेरी करने और हेरफेर करने के लिए अलग-अलग प्रतिमान पेश करती हैं। : XML, JSON, HTML, सादा पाठ प्रारूप : HTTP/HTTPS परिवहन प्रोटोकॉल प्रमुख अवधारणाएँ और विशेषताएँ : REST में, हर चीज़ एक संसाधन है। संसाधन एक वस्तु है जिसमें एक प्रकार, संबद्ध डेटा, अन्य संसाधनों से संबंध और उस पर काम करने वाले तरीकों का एक सेट होता है। संसाधनों की पहचान उनके यूआरआई (आमतौर पर एक यूआरएल) द्वारा की जाती है। संसाधन : आरईएसटी सेवाएं अक्सर संसाधनों पर सीधे सीआरयूडी (बनाएं, पढ़ें, अपडेट करें, हटाएं) संचालन पर मैप करती हैं। सीआरयूडी संचालन : REST सिस्टम मानक HTTP तरीकों का उपयोग करते हैं: 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 क्लाइंट-सर्वर मॉडल पर आधारित है। क्लाइंट उपयोगकर्ता इंटरफ़ेस और अनुभव के लिए ज़िम्मेदार है, जबकि सर्वर अनुरोधों को संसाधित करने, व्यावसायिक तर्क को संभालने और डेटा संग्रहीत करने के लिए ज़िम्मेदार है। क्लाइंट-सर्वर : सर्वर से प्रतिक्रियाएँ क्लाइंट द्वारा कैश की जा सकती हैं। सर्वर को यह बताना होगा कि कोई प्रतिक्रिया कैश करने योग्य है या नहीं। कैश करने योग्य : एक ग्राहक आमतौर पर यह नहीं बता सकता है कि यह सीधे अंतिम सर्वर से जुड़ा है या किसी मध्यस्थ से। मध्यस्थ सर्वर लोड संतुलन को सक्षम करके और साझा कैश प्रदान करके सिस्टम स्केलेबिलिटी में सुधार कर सकते हैं। स्तरित प्रणाली एप्लिकेशन स्टेट के इंजन के रूप में हाइपरमीडिया एक REST वेब सेवा सिद्धांत है जो ग्राहकों को वेब एप्लिकेशन के साथ बातचीत करने और नेविगेट करने में सक्षम बनाता है जो पूरी तरह से सर्वर द्वारा अपनी प्रतिक्रियाओं में गतिशील रूप से प्रदान किए गए हाइपरमीडिया पर आधारित है, जो ढीली युग्मन और खोज क्षमता को बढ़ावा देता है। HATEOAS: बक्सों का इस्तेमाल करें : कई वेब सेवाएँ 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 } आरपीसी और जीआरपीसी (रिमोट प्रोसीजर कॉल) एक प्रोटोकॉल है जो एक प्रोग्राम को किसी अन्य एड्रेस स्पेस में एक प्रक्रिया या सबरूटीन को निष्पादित करने की अनुमति देता है, जिससे वितरित सिस्टम के बीच निर्बाध संचार और डेटा विनिमय सक्षम होता है। आरपीसी (Google RPC) RPC के शीर्ष पर निर्मित एक आधुनिक, ओपन-सोर्स फ्रेमवर्क है जो परिवहन के लिए HTTP/2 और इंटरफ़ेस विवरण भाषा के रूप में प्रोटोकॉल बफ़र्स का उपयोग करता है, जो कुशल और मजबूत संचार की सुविधा के लिए प्रमाणीकरण, लोड संतुलन और बहुत कुछ जैसी सुविधाएँ प्रदान करता है। माइक्रोसर्विसेज के बीच। GRPC आरपीसी : 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); } साबुन , जो सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल के लिए है, कंप्यूटर नेटवर्क में वेब सेवाओं को लागू करने के लिए संरचित जानकारी के आदान-प्रदान के लिए एक प्रोटोकॉल है। यह एक XML-आधारित प्रोटोकॉल है जो अलग-अलग ऑपरेटिंग सिस्टम पर चलने वाले प्रोग्रामों को एक-दूसरे के साथ संचार करने की अनुमति देता है। SOAP : एक्सएमएल प्रारूप : HTTP/HTTPS, JMS, SMTP, और बहुत कुछ ट्रांसपोर्ट प्रोटोकॉल प्रमुख अवधारणाएँ और विशेषताएँ : SOAP संदेश XML में स्वरूपित होते हैं और इनमें निम्नलिखित तत्व होते हैं: 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> निष्कर्ष एपीआई आर्किटेक्चर शैलियों का परिदृश्य विविध है, जो आरईएसटी, एसओएपी, आरपीसी और अधिक जैसे विभिन्न दृष्टिकोण पेश करता है, प्रत्येक अद्वितीय ताकत और उपयोग के मामलों के साथ, डेवलपर्स को विभिन्न सॉफ्टवेयर के बीच स्केलेबल, कुशल और मजबूत एकीकरण के निर्माण के लिए सबसे उपयुक्त प्रतिमान चुनने में सक्षम बनाता है। घटक और प्रणालियाँ।
