REST और RPC के बीच वेब सेवा अंतर

98

मेरे पास एक वेब सेवा है जो JSON मापदंडों को स्वीकार करती है और विधियों के लिए विशिष्ट URL है, जैसे:

http://IP:PORT/API/getAllData?p={JSON}

यह निश्चित रूप से REST नहीं है क्योंकि यह स्टेटलेस नहीं है। यह कुकीज़ को ध्यान में रखता है और इसका अपना सत्र होता है।

क्या यह आरपीसी है? RPC और REST में क्या अंतर है?

web-services rest rpc

— Mazmart
स्रोत

1

अगर यह REST या RPC है तो यह क्यों मायने रखता है? आपके पूछने का कारण क्या है?

— बोगडान

5

यह सेवा मेरी नहीं है और यह बताती है कि यह आरईएसटी है, लेकिन ऐसा प्रतीत नहीं होता है। मैं यह पता लगाना चाहता था कि कहीं मैं इसके बारे में गलत तो नहीं हूं।

— Mazmart

101

@ बोगदान ज्ञान कारण है।

— सर

68

आप जो पोस्ट कर रहे हैं उसे देखकर आप REST या RPC के बीच स्पष्ट अलगाव नहीं कर सकते।

REST का एक अवरोध यह है कि इसे स्टेटलेस होना चाहिए। यदि आपके पास एक सत्र है तो आपके पास राज्य है इसलिए आप अपनी सेवा को RESTful नहीं कह सकते।

तथ्य यह है कि आपके यूआरएल में एक कार्रवाई (यानी getAllData) आरपीसी के लिए एक संकेत है। REST में आप अभ्यावेदन का आदान-प्रदान करते हैं और आपके द्वारा किया गया संचालन HTTP क्रियाओं द्वारा निर्धारित होता है। इसके अलावा, आरईएसटी में, सामग्री बातचीत एक ?p={JSON}पैरामीटर के साथ नहीं की जाती है ।

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

— Bogdan
स्रोत

तो Restful का मतलब है कि यह REST के अलावा सभी मानकों का पालन कर रहा है जब वह मानकों का पालन नहीं करना चुन सकता है?

— Mazmart

3

@Mazmart: REST दिशानिर्देशों और बाधाओं का एक समूह है। यह एक कल्पना नहीं है कि कोई भी लागू कर सकता है और जब वे एक RESTful सेवा का दावा करते हैं। मैंने जो देखा है, उसमें से ज्यादातर लोग किसी भी चीज का उल्लेख करते हैं जो SOAP REST के रूप में नहीं है , जब वास्तव में RPC का कुछ अन्य प्रकार है।

— बोगदान

120

HTTP APIs के निम्नलिखित उदाहरण पर विचार करें जो एक रेस्तरां में रखा जा रहा है।

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

एक ऑर्डर देना:

RPC: http: // MyRestaurant: 8080 / ऑर्डर / प्लेसऑर्डर (POST: { टैकोस ऑब्जेक्ट})
REST: http: // MyRestaurant: 8080 / आदेश / आदेश? ऑर्डरनंबर = asdf (पोस्ट: { टैकोस ऑब्जेक्ट})

एक आदेश वापस लेना:

एक आदेश अद्यतन:

RPC: http: // MyRestaurant: 8080 / ऑर्डर / अपडेटऑर्डर (PUT: {अनानास टैकोस ऑब्जेक्ट})
REST: http: // MyRestaurant: 8080 / ऑर्डर / ऑर्डर? ऑर्डरनंबर = asdf (PUT: {अनानास टैकोस ऑब्जेक्ट})

साइट्स से लिया गया उदाहरण। URLsite/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc

— गौरव
स्रोत

32

अंत में कुछ URL उदाहरण हैं।

— फेबियन पॉनिक

4

URL के संबंध में आप जो कह रहे हैं, मैं उससे सहमत नहीं हूँ। आपके पास एक ही URL पर सभी RPC कॉल और विभिन्न URL पर REST हो सकते हैं। आप सिक्के का केवल एक पक्ष दिखा रहे हैं।

— बेसिकरल

आप यहाँ जो बता रहे हैं, वह REST नहीं है - REST एक वास्तुशिल्प पैटर्न है। आप जो वर्णन कर रहे हैं वह HTTP पर REST है, जो कि ज्यादातर लोग सोचते हैं कि वे REST के बारे में कब बात करते हैं।

— d4nyll

36

जैसा कि दूसरों ने कहा है, एक महत्वपूर्ण अंतर यह है कि REST संज्ञा-केंद्रित है और RPC क्रिया-केंद्रित है। मैं केवल उदाहरणों के इस स्पष्ट तालिका को प्रदर्शित करना चाहता था, जिसमें यह दर्शाया गया है:

--------------------------- + ---------------------- --------------- + --------------------------
  ऑपरेशन                  | आरपीसी (ऑपरेशन)                      | बाकी (संसाधन)
--------------------------- + ---------------------- --------------- + --------------------------
 साइनअप | POST / साइनअप | पोस्ट / व्यक्ति           
--------------------------- + ---------------------- --------------- + --------------------------
 इस्तीफा | POST / इस्तीफा | DELETE / व्यक्ति / 1234    
--------------------------- + ---------------------- --------------- + --------------------------
 व्यक्ति पढ़ें | GET / रीडपर्सन? Personid = 1234 | GET / व्यक्तियों / 1234       
--------------------------- + ---------------------- --------------- + --------------------------
 व्यक्ति की वस्तुओं की सूची पढ़ें | GET / readUserItemsList? Userid = 1234 | GET / व्यक्तियों / 1234 / आइटम
--------------------------- + ---------------------- --------------- + --------------------------
 व्यक्ति की सूची में आइटम जोड़ें | POST / addItemToUsersItemsList | पोस्ट / व्यक्ति / 1234 / आइटम
--------------------------- + ---------------------- --------------- + --------------------------
 अपडेट आइटम | पोस्ट / संशोधित करें | PUT / आइटम / 456          
--------------------------- + ---------------------- --------------- + --------------------------
 आइटम हटाएँ | POST / removeItem? ItemId = 456 | DELETE / आइटम / 456       
--------------------------- + ---------------------- --------------- + --------------------------

टिप्पणियाँ

जैसा कि तालिका से पता चलता है, REST विशिष्ट संसाधनों
(जैसे GET /persons/1234) की पहचान करने के लिए URL पथ मापदंडों का उपयोग करने के लिए जाता है , जबकि RPC फ़ंक्शन इनपुट्स
(जैसे GET /readPerson?personid=1234) के लिए क्वेरी मापदंडों का उपयोग करती है ।
तालिका में नहीं दिखाया गया है कि एक REST API फ़िल्टरिंग को कैसे हैंडल करेगा, जिसमें आमतौर पर क्वेरी पैरामीटर (जैसे GET /persons?height=tall) शामिल होंगे।
यह भी नहीं दिखाया गया है कि या तो सिस्टम के साथ कैसे है, जब आप ऑपरेशन बनाते / अपडेट करते हैं, तो अतिरिक्त डेटा संभवतः संदेश बॉडी के माध्यम से पारित किया जाता है (जैसे जब आप करते हैं POST /signupया POST /persons, आप नए व्यक्ति का वर्णन करने वाला डेटा शामिल करते हैं)।
बेशक, इसमें से कोई भी पत्थर में सेट नहीं है, लेकिन इससे आपको अंदाजा हो जाता है कि आपको मुठभेड़ की क्या संभावना है और आप किस तरह से स्थिरता के लिए अपना खुद का एपीआई व्यवस्थित कर सकते हैं। REST URL डिज़ाइन की अधिक चर्चा के लिए, यह प्रश्न देखें ।

— MarredCheese
स्रोत

28

यह http का उपयोग करके RPC है । REST का सही क्रियान्वयन RPC से भिन्न होना चाहिए। एक विधि / कार्य की तरह, डेटा को संसाधित करने के लिए एक तर्क है, RPC है। getAllData () एक बुद्धिमान विधि है। REST में बुद्धिमत्ता नहीं हो सकती है, यह डंप डेटा होना चाहिए जिसे बाहरी बुद्धिमत्ता द्वारा क्वियर किया जा सकता है ।

अधिकांश कार्यान्वयन जो मैंने इन दिनों देखे हैं वे आरपीसी हैं लेकिन कई लोग इसे गलती से आरईएसटी कहते हैं। HTTP वाला REST XML खलनायक के साथ उद्धारक और SOAP है। तो आपका भ्रम उचित है और आप सही हैं, यह REST नहीं है।

Http प्रोटोकॉल REST का कार्यान्वयन नहीं करता है। REST (GET, POST, PUT, PATCH, DELETE) और RPC (GET + POST) दोनों को HTTP (जैसे: विजुअल स्टूडियो में एक वेब एपीआई परियोजना के माध्यम से) के माध्यम से विकसित किया जा सकता है।

ठीक है, लेकिन फिर REST क्या है? रिचर्डसन परिपक्वता मॉडल नीचे (संक्षेप में) दिया गया है। केवल स्तर 3 रेस्टफुल है।

लेवल 0: एचटीपी पोस्ट
स्तर 1: प्रत्येक संसाधन / इकाई का एक यूआरआई है (लेकिन अभी भी केवल पोस्ट)
स्तर 2: POST और GET दोनों का उपयोग किया जा सकता है
लेवल 3 (RESTful): HATEOAS (हाइपर मीडिया लिंक) या दूसरे शब्दों में सेल्फ एक्सप्लोरेटरी लिंक का उपयोग करता है

उदाहरण: स्तर 3 (HATEOAS):

लिंक बताता है कि इस ऑब्जेक्ट को इस तरह से अपडेट किया जा सकता है, और इस तरह से जोड़ा जा सकता है।
लिंक बताता है कि यह ऑब्जेक्ट केवल पढ़ा जा सकता है और यह है कि हम इसे कैसे करते हैं।

स्पष्ट रूप से, डेटा भेजना REST बनने के लिए पर्याप्त नहीं है, लेकिन डेटा की क्वेरी कैसे की जाए, इसका भी उल्लेख किया जाना चाहिए। लेकिन फिर, 4 कदम क्यों? यह केवल चरण 4 क्यों नहीं हो सकता है और इसे REST क्यों नहीं कहा जा सकता है? रिचर्डसन ने हमें वहां पहुंचने के लिए कदम दर कदम एक कदम दिया, बस इतना ही।

आपने ऐसी वेब साइटें बनाई हैं जिनका उपयोग मनुष्य कर सकता है। लेकिन क्या आप उन वेब साइटों का भी निर्माण कर सकते हैं जो मशीनों द्वारा उपयोग करने योग्य हैं? यही वह जगह है जहां भविष्य निहित है, और रेस्टफुल वेब सर्विसेज आपको बताती हैं कि यह कैसे करना है।

यह पुस्तक रेस्टफुल वेब सर्विसेज मदद करती है
एक बहुत ही दिलचस्प RPC बनाम REST पढ़ा

पुनश्च: REST सुपर लोकप्रिय है इसलिए स्वचालित परीक्षण किया जाता है लेकिन जब वास्तविक दुनिया के उदाहरणों की बात आती है तो .. अच्छा है।

— नीला बादल
स्रोत

1

पहला पैराग्राफ बहुत ही सरल और सीधे तरीके से अंतर की व्याख्या करता है। मेरे +1 :)

— निकोलस

12

आरईएसटी को संसाधनों के साथ काम करने के लिए सबसे अच्छा वर्णन किया गया है, जहां आरपीसी कार्यों के बारे में अधिक है।

आराम अर्थ है प्रतिनिधि राज्य अंतरण। यह स्वतंत्र प्रणालियों के बीच बातचीत को व्यवस्थित करने का एक सरल तरीका है। Restful एप्लिकेशन आमतौर पर डेटा (पोस्ट और / या अपडेट) पोस्ट डेटा (उदाहरण के लिए, प्रश्न करें), और डेटा को हटाने के लिए HTTP अनुरोधों का उपयोग करते हैं। इस प्रकार, REST सभी चार CRUD (क्रिएट / रीड / अपडेट / डिलीट) ऑपरेशंस के लिए HTTP का उपयोग कर सकता है।

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

— इरशाद
स्रोत

4

मैं इस प्रकार तर्क दूंगा:

क्या मेरी संस्था के पास डेटा है / है? फिर आरपीसी: यहां मेरे कुछ डेटा की एक प्रति है, जो डेटा कॉपी मैं आपको भेजता हूं, उसमें हेरफेर करें और अपने परिणाम की एक कॉपी मुझे वापस कर दें।

क्या इकाई डेटा को धारण / करती है? तब REST: या तो (1) मुझे अपने कुछ डेटा की एक प्रति दिखाएं या (2) अपने कुछ डेटा में हेरफेर करें।

अंततः यह उस बारे में है जो कार्रवाई का "पक्ष" डेटा का मालिक / रखता है। और हाँ, आप RPC-आधारित प्रणाली से बात करने के लिए REST वर्बेज का उपयोग कर सकते हैं, लेकिन आप अभी भी ऐसा करने के बाद RPC गतिविधि कर रहे हैं।

उदाहरण 1: मेरे पास एक ऑब्जेक्ट है जो एक डीएओ के माध्यम से एक रिलेशनल डेटाबेस स्टोर (या किसी अन्य प्रकार के डेटा स्टोर) पर संचार कर रहा है। मेरी वस्तु और डेटा एक्सेस ऑब्जेक्ट के बीच REST शैली का उपयोग करने के लिए समझ में आता है जो कि API के रूप में मौजूद हो सकता है। मेरी इकाई डेटा का स्वामित्व / धारण नहीं करती है, रिलेशनल डेटाबेस (या गैर-रिलेशनल डेटा स्टोर) करता है।

उदाहरण 2: मुझे बहुत सारे जटिल गणित करने की आवश्यकता है। मैं अपनी विधियों में गणित के तरीकों का एक गुच्छा लोड नहीं करना चाहता, मैं बस कुछ मूल्यों को कुछ और से गुजारना चाहता हूं जो सभी प्रकार के गणित कर सकते हैं, और एक परिणाम प्राप्त कर सकते हैं। फिर आरपीसी शैली समझ में आती है, क्योंकि गणित वस्तु / इकाई मेरे ऑब्जेक्ट को संचालन के पूरे समूह के लिए उजागर करेगी। ध्यान दें कि इन विधियों को व्यक्तिगत API के रूप में उजागर किया जा सकता है और मैं उनमें से किसी को भी GET कह सकता हूं। मैं यह भी दावा कर सकता हूं कि यह RESTful है क्योंकि मैं HTTP GET के माध्यम से कॉल कर रहा हूं लेकिन वास्तव में कवर के तहत यह RPC है। मेरी इकाई डेटा का मालिक है / रखती है, दूरस्थ इकाई केवल उस डेटा की प्रतियों पर जोड़-तोड़ कर रही है जो मैंने उसे भेजी थी।

— जॉन टुल्लिस
स्रोत

4

एचटीटीपी पर वे दोनों सिर्फ HttpRequestवस्तुओं के रूप में समाप्त होते हैं और वे दोनों एक HttpResponseवस्तु की उम्मीद करते हैं। मुझे लगता है कि कोई उस विवरण के साथ कोडिंग जारी रख सकता है और किसी और चीज के बारे में चिंता कर सकता है।

— acmoune
स्रोत

2

यहाँ अच्छे उत्तरों का गुच्छा है। मैं अभी भी आपको इस Google ब्लॉग का उल्लेख करूंगा क्योंकि यह RPC और REST के बीच के अंतरों पर चर्चा करने का एक बहुत अच्छा काम करता है और कुछ को कैप्चर करता है जो मैंने यहां किसी भी उत्तर में नहीं पढ़ा था।

मैं उसी लिंक से एक पैराग्राफ उद्धृत करूंगा जो मेरे पास था:

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

— मि। मैट्रिक्स
स्रोत

1

यह मैं अलग-अलग उपयोग मामलों में समझता हूं और उनका उपयोग करता हूं:

उदाहरण: रेस्तरां प्रबंधन

REST के लिए उपयोग-केस : ऑर्डर प्रबंधन

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

संसाधन प्रबंधन के लिए, REST स्वच्छ है। पूर्व-परिभाषित क्रियाओं के साथ एक समापन बिंदु। इसे दुनिया में DB (Sql या NoSql) या वर्ग उदाहरणों को उजागर करने का एक तरीका के रूप में देखा जा सकता है।

कार्यान्वयन उदाहरण:

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

फ्रेमवर्क उदाहरण: अजगर के लिए फाल्कन।

RPC के लिए उपयोग मामला : ऑपरेशन प्रबंधन

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

विश्लेषणात्मक, परिचालन, गैर-उत्तरदायी, गैर-प्रतिनिधि, एक्शन-आधारित नौकरियों के लिए, आरपीसी बेहतर काम करता है और कार्यात्मक होना बहुत स्वाभाविक है।

कार्यान्वयन उदाहरण:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

फ्रेमवर्क उदाहरण: अजगर के लिए फ्लास्क

— अली खोसरो
स्रोत