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