REST को वेब के लिए डिज़ाइन किया गया था, और वेब को REST के लिए डिज़ाइन किया गया था। दोनों बस एक साथ फिट होंगे। रॉय फील्डिंग की 2000 पीएचडी थीसिस आर्किटेक्चरल शैलियाँ और नेटवर्क-आधारित सॉफ़्टवेयर आर्किटेक्चर के डिज़ाइन ने REST शब्द को परिभाषित और पेश किया , और वेब और REST के बीच महत्वपूर्ण अंतर है: रॉय फील्डिंग ने HTTP / 1.1 पर काम किया, जिसमें से वह प्राथमिक लेखक हैं, और उन्होंने अपने शोध प्रबंध में REST का वर्णन करने के लिए वहां जो कुछ भी सीखा, उसका इस्तेमाल किया।
तो, वेब और REST इतनी अच्छी तरह से एक साथ चलते हैं इसका सीधा सा कारण यह है कि REST की परिभाषा यह बताई गई है कि वेब कैसे काम करता है, और वेब REST का कार्यान्वयन है।
यही कारण है कि REST वेब सेवाओं और वेब ऐप के लिए एक अच्छा फिट है: क्योंकि आप बस वही काम करते हैं जो पहले से ही "मानव" वेब में काम करने के लिए साबित हो चुके हैं, और उन्हें "मशीन" वेब पर लागू करते हैं।
बड़ा RPC (पर निर्भर करता है के साथ समस्या यह सटीक कार्यान्वयन) में मूल रूप से निहित है वितरित कम्प्यूटिंग का भ्रम है, जिसमें अधिक विस्तार से वर्णन किया श्वेतपत्र अर्नोन रोटेम-Gal-ओज से इस :
- नेटवर्क विश्वसनीय है
- विलंबता शून्य है
- बैंडविड्थ अनंत है
- नेटवर्क सुरक्षित है
- टोपोलॉजी नहीं बदलती
- एक प्रशासक है
- परिवहन लागत शून्य है
- नेटवर्क सजातीय है
ये सभी धारणाएं हैं जो नए लोग आमतौर पर वितरित सिस्टम बनाने के लिए शुरू करते हैं। बेशक, वे सभी झूठे हैं। और आपको वितरित सिस्टम बनाते समय उन सभी को ध्यान में रखना होगा।
कई आरपीसी कार्यान्वयनों के साथ समस्या यह है कि वे दूरस्थ कॉल को स्थानीय कॉल की तरह बनाने की कोशिश करते हैं। लेकिन वे एक जैसे नहीं हैं:
- एक स्थानीय कॉल कभी विफल नहीं होता है; सबरूटीन है कि आप असफल हो सकता है कहा जाता है, लेकिन कॉल खुद कभी नहीं करता है - एक दूरस्थ कॉल नेटवर्क पर खो सकती है
- एक स्थानीय कॉल तात्कालिक है; सबरूटीन (अगर यह अनंत लूप में अटक जाता है यहां तक कि हमेशा के लिए या) आप नामक एक लंबे समय के लिए चला सकते हैं, लेकिन कॉल ही कुछ ही समय में सभी (अच्छी तरह से, सीपीयू निर्देश के एक मुट्ठी भर में अधिक से अधिक लेता है, कम करता है, तो कॉल है अंतर्निर्मित, लेकिन यह बहुत तेज़ है) - एक दूरस्थ कॉल लंबे समय तक नेटवर्क पर अटक सकती है
- यदि सबरूटीन सामान्य रूप से लौटता है, तो परिणाम हमेशा वापस आता है - रिमोट कॉल के साथ, परिणाम नेटवर्क पर खो सकता है
- रिटर्न तात्कालिक हैं - दूरस्थ परिणाम लंबे समय तक नेटवर्क पर यात्रा कर सकते हैं
- अगर मैं एक बार एक सबरूटीन को कॉल करता हूं, तो यह एक बार ठीक से चलेगा - एक रिमोट कॉल नेटवर्क पर खो सकता है, या डुप्लिकेट हो सकता है इसलिए दूरस्थ दिनचर्या 0 और किसी भी समय के बीच चल सकती है
- मुझे ठीक एक परिणाम मिलता है - एक दूरस्थ परिणाम खो सकता है या दोहराया जा सकता है, इसलिए आपको परिणाम 0 या अधिक बार मिल सकता है
- यदि मैं दो बार सबरूटीन कॉल करता हूं, तो मुझे दो परिणाम मिलते हैं और दूसरी कॉल के परिणाम से पहले मुझे पहली कॉल का परिणाम मिलता है - आप शायद अब तक इसका अनुमान लगा सकते हैं: आरपीसी के साथ, आपको कोई परिणाम वापस नहीं मिल सकता है, या केवल पहला , या केवल दूसरे, या पहले से पहले दूसरा, या पहला खो सकता है और आपको दूसरा दो बार मिलता है, या दूसरे तरीके से, और इसी तरह…
- यदि मैं फोन करता हूं
aऔर फिर b, मुझे उसका परिणाम वापस मिल जाता है aऔर फिर परिणाम b - यह पिछले बिंदु का एक सामान्य संस्करण है, तो आरपीसी के साथ, आपको किसी भी क्रम में 0 या अधिक बार दोनों में से कोई भी उत्तर मिल सकता है।
आप करेंगे एक दूरस्थ कॉल के लिए ऊपर के सभी के साथ सौदा है। लेकिन अगर आपका ढांचा स्थानीय कॉल से दूरस्थ कॉल को अप्रभेद्य बनाता है, तो आप नहीं कर सकते , क्योंकि आप नहीं जानते कि कौन से रिमोट कॉल हैं। फ़्रेमवर्क आपके लिए उन सभी को आज़मा सकता है, लेकिन समस्या यह है: फ़्रेमवर्क आपके सिस्टम के बारे में उतना नहीं जानता जितना आप करते हैं। यह नहीं जानता कि क्या कॉल हैं जहां वास्तव में कोई फर्क नहीं पड़ता अगर कोई एक बार में एक बार खो जाता है। इसलिए, रूपरेखा को बहुत रक्षात्मक होना चाहिए, और यह विलंबता और बैंडविड्थ के संदर्भ में महंगा है।
खासकर क्योंकि फ्रेमवर्क वास्तव में आपको ढाल नहीं सकता है । कैप प्रमेय का कहना है कि एक वितरित प्रणाली, लगातार उपलब्ध है, और विभाजन-सहिष्णु एक ही समय में नहीं हो सकता है; अधिक सटीक रूप से, यह कहता है कि एक बार विभाजन होने के बाद, सिस्टम निरंतर और उपलब्ध दोनों नहीं रह सकता है, इसे एक को चुनना होगा (लोकप्रिय विश्वास के विपरीत, प्रमेय यह नहीं कहता है कि आपके पास तीन नहीं हो सकते हैं, जब सिस्टम चल रहा है आम तौर पर, आपके पास तीनों हो सकते हैं, लेकिन एक बार जब आपके पास एक विभाजन होता है, तो आपको अन्य दो में से एक को चुनना होगा)। PACELC प्रमेय दिखा रहा है कि यहां तक कि जब प्रणाली काम कर रहा है, तो आप व्यापार बंद करने के लिए बनाम संगति विलंबता है द्वारा कैप प्रमेय फैली हुई है।
ये महत्वपूर्ण ट्रेड-ऑफ हैं जो फ्रेमवर्क आपको बहुत अधिक ढाल नहीं सकते हैं, क्योंकि वे मूल डिजाइन के लिए डोमेन-विशिष्ट और महत्वपूर्ण हैं।
एर्लैंग की तरह एक दृष्टिकोण के साथ इसका विरोध करें, जो काम करता है : एर्लैंग में, सभी संदेश प्रेषितों को रिमोट के रूप में माना जाता है, भले ही वे स्थानीय हों। इसका मतलब है कि आप उपरोक्त सभी समस्याओं (और कई और अधिक) से निपटने के लिए हमेशा तैयार हैं। स्थानीय प्रक्रियाओं के लिए, इन करते हैं , एक ओवरहेड का एक छोटा सा खड़ा है, हालांकि। इसमें मदद करने के लिए, त्रुटि से निपटने और पर्यवेक्षण के लिए उपकरण, फ्रेमवर्क, लाइब्रेरी, पैटर्न, और मुहावरों की बड़ी संख्या है।
आपने यह वर्णन नहीं किया है कि आपका RPC फ्रेमवर्क विशेष रूप से कैसे काम करता है, और आप किस भाषा या लाइब्रेरी का उपयोग कर रहे हैं, लेकिन मुझे इस बात का पक्का संदेह है कि यह पूर्व के "नेटवर्क का अस्तित्व नहीं है" प्रकार का है। वे सिर्फ काम नहीं करते। यह है ठीक इलाज स्थानीय और दूरस्थ कॉल के बीच भेद को दूर करने के लिए सब कुछ एक के रूप में दूरदराज के कॉल। इसे अमूर्त के चारों ओर दूसरे तरीके से करना: नेटवर्क आपके सिस्टम का हिस्सा है, यदि आप इसे दूर करते हैं, तो आप कुछ ऐसा करते हैं, जिसके बारे में आपको वास्तव में जानने की जरूरत है।
अब, आपको विशेष रूप से REST का उपयोग करना है या नहीं, यह एक पूरी तरह से अलग सवाल है। जैसा कि मैंने ऊपर बताया, वेब को REST के लिए डिज़ाइन किया गया था और REST को वेब के लिए डिज़ाइन किया गया था, इसलिए दोनों एक साथ काम करते हैं, लेकिन आप चाहें तो अन्य वास्तुशिल्प शैलियों का उपयोग कर सकते हैं। लेकिन आपके सवाल का कम से कम हिस्सा "क्यों नहीं आरपीसी था" के बारे में था, और मैंने ऊपर दिए गए कारणों को निर्धारित किया, और अधिक सटीक रूप से मैंने समझाया कि जिस प्रकार का आरपीसी मुझे संदेह है कि आप उपयोग कर रहे हैं वह आपको परेशानी में डाल सकता है।