REST बनाम JSON-RPC? [बन्द है]

251

बंद हो गया । यह सवाल राय आधारित है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि इस पोस्ट को संपादित करके तथ्यों और उद्धरणों के साथ उत्तर दिया जा सके ।

8 महीने पहले बंद हुआ ।

इस प्रश्न को सुधारें

मैं वेब एप्लिकेशन के लिए API विकसित करने के लिए REST और JSON-RPC के बीच चयन करने का प्रयास कर रहा हूं। वे कैसे तुलना करते हैं?

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

rest rpc json-rpc

— अली शकीबा
स्रोत

29

REST निश्चित रूप से लोकप्रिय जवाब है। मुझे यकीन नहीं है कि यह हमेशा सही जवाब है। एक संसाधन-केंद्रित REST API और एक समस्या डोमेन के बीच एक बाधा बेमेल हो सकता है जो स्वाभाविक रूप से कार्य या वर्कफ़्लो आधारित है। यदि आप पाते हैं कि आपको एक ही संसाधन पर विभिन्न प्रकार के पैटेक करने हैं या कुछ कार्य विशिष्ट संसाधन के लिए मैप नहीं करते हैं, तो आपको REST प्रतिमान को मोड़ना शुरू करना होगा। क्या आप संसाधनों के रूप में कार्यों / आदेशों का उपयोग करते हैं। क्या आप सामग्री-प्रकार हेडर में कमांड प्रकारों को मापदंडों के रूप में भिन्न करते हैं? निश्चित नहीं है कि सभी उत्तर एक-आकार के हैं।

— लैंडन पोच

27

JSON-RPC सरल और सुसंगत है, उपयोग करने के लिए एक खुशी है।

— dnault

1

इसके अगस्त 2015 में, मैंने REST का उपयोग करते हुए क्लाइंट और सर्वर दोनों को लागू किया है, पहले 2 दिन सीख रहा था फिर मैंने समझा कि यह लोकप्रिय क्यों था। एक छोटा सा ऐप बन जाने के बाद यह वास्तविक आनंद था, क्लाइंट के पास विभिन्न यूआरएल पथ को याद रखने के लिए कोई काम नहीं होता है, नोड पर सर्वर और जावास्क्रिप्ट में क्लाइंट साझा करने के लिए समान संरचना (यूआरएल पथ) साझा करता है। वाह! यह बहुत तेज था, उत्पाद केवल 15 दिनों में डिलीवर हो गया, यहां तक कि स्क्रैच से भी लिखना। REST रास्ता है। यह भी ध्यान दें कि लोकप्रिय Apache CouchDB REST का उपयोग करता है, जो एक महान डेटाबेस हैं, बहुत गर्व है कि उन्होंने REST में भी किया। सरल में, REST स्वच्छ इंटरफ़ेस के साथ RIGHT (सही) है।

— मनोहर रेड्डी Poreddy

6

यह आपके पास या आपके प्राथमिक लक्ष्य की बाधाओं पर निर्भर करता है। उदाहरण के लिए, यदि प्रदर्शन आपके जाने का एक प्रमुख पहलू है JSON-RPC (जैसे उच्च प्रदर्शन कम्प्यूटिंग)। यदि आपका प्राथमिक लक्ष्य अज्ञेयवादी होना है, ताकि दूसरों द्वारा व्याख्या किए जाने के लिए एक सामान्य इंटरफ़ेस प्रदान किया जा सके, तो आपका जाने का तरीका REST है। यदि आप दोनों लक्ष्य चाहते हैं, तो आपको दोनों प्रोटोकॉल शामिल करने होंगे। आपकी आवश्यकताओं के समाधान को परिभाषित करते हैं।

— स्टैथिस एंड्रोनिकोस

@StathisAndronikos आप सही हैं, मेरा मुख्य लक्ष्य उपयोग में आसानी और वेब ऐप्स के लिए एक अच्छा प्रदर्शन था (एचपीसी नहीं)।

— अली शकीबा

221

RPC के साथ मूलभूत समस्या युग्मन है। RPC क्लाइंट कई तरह से सेवा कार्यान्वयन के लिए कसकर युग्मित हो जाते हैं और ग्राहकों को तोड़े बिना सेवा कार्यान्वयन को बदलना बहुत मुश्किल हो जाता है:

प्रक्रिया के नाम जानने के लिए ग्राहकों की आवश्यकता होती है;
प्रक्रिया पैरामीटर आदेश, प्रकार और गिनती मामले। क्लाइंट हस्ताक्षर को तोड़े बिना सर्वर साइड पर प्रक्रिया हस्ताक्षर (तर्कों की संख्या, तर्कों का क्रम, तर्क आदि ...) को बदलना आसान नहीं है;
RPC शैली कुछ भी नहीं लेकिन प्रक्रिया समापन बिंदु + प्रक्रिया तर्क को उजागर नहीं करती है। ग्राहक के लिए यह निर्धारित करना असंभव है कि आगे क्या किया जा सकता है।

दूसरी ओर REST शैली में ग्राहकों को मार्गदर्शन में नियंत्रण जानकारी (HTTP हेडर + प्रतिनिधित्व) शामिल करके मार्गदर्शन करना बहुत आसान है। उदाहरण के लिए:

यह संभव है (और वास्तव में अनिवार्य है) लिंक संबंध प्रकारों के साथ एनोटेट किए गए लिंक जो इन यूआरआई के अर्थ व्यक्त करते हैं;
ग्राहक कार्यान्वयन को विशेष प्रक्रिया के नाम और तर्कों पर निर्भर होने की आवश्यकता नहीं है। इसके बजाय, ग्राहक संदेश प्रारूपों पर निर्भर करते हैं। यह विशेष रूप से मीडिया प्रारूपों (जैसे एटम, HTML, संग्रह + JSON, HAL इत्यादि) के लिए पहले से लागू पुस्तकालयों का उपयोग करने की संभावना बनाता है)
जहां तक वे केवल पंजीकृत (या डोमेन विशिष्ट) लिंक संबंधों पर निर्भर हैं, ग्राहकों को तोड़ने के बिना यूआरआई को आसानी से बदलना संभव है;
अभ्यावेदन में फ़ॉर्म-जैसी संरचनाओं को एम्बेड करना संभव है, जिससे ग्राहकों को इन क्षमताओं को यूआई क्षमताओं के रूप में उजागर करने की संभावना मिलती है यदि अंतिम उपयोगकर्ता मानव है;
कैशिंग के लिए समर्थन अतिरिक्त लाभ है;
मानकीकृत स्थिति कोड;

REST की तरफ कई और अंतर और फायदे हैं।

— योसेब
स्रोत

20

"लिंक संबंध प्रकारों के साथ एनोटेट किए गए लिंक को एम्बेड करना अनिवार्य है, जिसका अर्थ क्या है .."?

— पीजे

129

"ग्राहकों को प्रक्रिया के नाम जानने की आवश्यकता है" - यह तर्क नहीं है क्योंकि REST के साथ यह नाम यूआरआई में इस पैरामीटर को पारित करने के बजाय हार्डकोड किया गया है। अन्यथा सर्वर को यह पता नहीं चलेगा कि उसे कौन सी विधि करनी चाहिए।

— सेंचुरियन

44

"यह क्लाइंट हस्ताक्षर को तोड़ने के बिना सर्वर साइड पर ... प्रक्रिया हस्ताक्षर बदलने के लिए आसान नहीं है", यह भी बहस का मुद्दा है। REST और JSON-RPC दोनों SOAP नहीं हैं और इसमें WSDL नहीं है जो मौजूदा वेब सेवाओं और उनके प्रकारों का वर्णन करता है ताकि क्लाइंट पक्ष पर गतिशील परिवर्तन के लिए उपयोग किया जा सके। इसलिए, यदि आप वेब सेवा बदलते हैं तो आपको क्लाइंट को बदलना होगा। अन्यथा आपको SOAP के साथ जाने की आवश्यकता है।

— सेंचुरियन

64

मैंने एप्लिकेशन को कोडित किया है और फिर भी कोई लचीली वेब सेवा नहीं देखी है। यदि आप बैकएंड और वेब सेवाओं को बदलते हैं तो क्लाइंट को हमेशा नई आवश्यकताओं को पूरा करने के लिए रिफलेक्ट / अपडेट किया जाना चाहिए। और मैंने SOAP का उल्लेख किया है और क्योंकि इसमें कुछ ऐसा है जो लचीलापन देता है, जैसे WSDL, इसलिए आप कुछ को स्वचालित कर सकते हैं और अधिक लचीलापन हो सकते हैं क्योंकि आप परिणाम सेट, डेटाटिप्स और उपलब्ध वेब सेवाओं के बारे में जानकारी प्राप्त कर सकते हैं। बाकी और अन्य के पास ऐसा बिल्कुल नहीं है। इसलिए न तो REST, न ही JSON-RPC, और न ही अन्य वेब सेवा प्रकार आपको जादू देगा जो मैन्युअल क्लाइंट अपडेट की आवश्यकता को समाप्त कर देगा।

— सेंचुरियन

15

मेरे लिए, मेरी वर्तमान टीम और पिछली टीमें, RESTful वेब सेवाएं CRUD प्रकार के अनुप्रयोगों के लिए हैं। "जब हम सर्वर पर कुछ बदलते हैं तो क्या हम हर बार ब्राउज़रों को फिर से लिखते हैं?" - नहीं, क्योंकि ब्राउज़र सिर्फ HTTP निष्पादक हैं, उनका व्यावसायिक तर्क से कोई लेना-देना नहीं है, क्लाइंट प्रोग्राम को क्रियान्वित करने की जरूरत है (स्क्रीन दिखाओ, संबंधित सामग्री का प्रदर्शन करें)। ऐसा लगता है कि हमने लौ युद्ध शुरू कर दिया है, लेकिन सामान्य तौर पर मैं चाहता हूं कि मेरे पास व्यावहारिक उपयोग प्रवाह के साथ RESTfull वेब सेवाओं के लिए एक और ठोस स्रोत होगा, जिसमें जादुई लचीलापन है जिसका आप उल्लेख कर रहे हैं। इस बीच बहुत सारे कथन भी अस्पष्ट हैं।

— सेंचुरियन

163

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

यदि आप RPC पर निर्णय लेते हैं, तो एकमात्र अंतर यह है कि आप स्पष्ट रूप से क्रिया को URI के भाग के रूप में निर्दिष्ट कर रहे हैं, जो स्पष्ट, सुसंगत, कम छोटी गाड़ी है, और वास्तव में कोई परेशानी नहीं है। विशेष रूप से यदि आप एक ऐप बनाते हैं जो सरल सीआरयूडी से आगे निकलता है, तो आरपीसी एकमात्र रास्ता है। RESTful purists के साथ मेरा एक और मुद्दा है: HTTP POST, GET, PUT, DELETE का HTTP में निश्चित अर्थ है जो कि अन्य चीजों में REST द्वारा हटा दिया गया है, बस इसलिए कि वे ज्यादातर समय में फिट होते हैं - लेकिन सभी समय के साथ।

प्रोग्रामिंग में, मैंने बहुत पहले पाया है कि एक चीज का उपयोग करने की कोशिश करने का मतलब है कि दो चीजें कुछ समय के आसपास आने वाली हैं और आपको काटती हैं। मुझे हर एक्शन के बारे में POST का उपयोग करने की क्षमता प्राप्त करना पसंद है, क्योंकि यह डेटा भेजने और प्राप्त करने की स्वतंत्रता प्रदान करता है, क्योंकि आपकी विधि को करने की आवश्यकता है। आप पूरी दुनिया को CRUD में फिट नहीं कर सकते।

— ब्रूस पाटन
स्रोत

30

यह जवाब वास्तव में REST वास्तव में क्या है की सभी-बहुत गलत धारणा को दर्शाता है। REST निश्चित रूप से HTTP विधियों में CRUD का मात्र मानचित्रण नहीं है। यह विचार कि यह "एक और विधि जोड़ने" की समस्या है, स्पष्ट रूप से इंगित करता है कि REST को HTTP पर RPC के रूप में गलत समझा गया है, जो कि ऐसा बिल्कुल नहीं है। रॉय फील्डिंग ब्लॉग या उनके शोध प्रबंध को पढ़ने की कोशिश करें - Google आपको इसे ढूंढने में मदद करेगा - आप अपने उत्तर में REST का बिल्कुल भी वर्णन नहीं कर रहे हैं।

— नेपदेव

68

मैं बहुत ही व्यवहारिक व्यक्ति हूं। REST के सभी विवरण जो मैंने स्पष्ट रूप से पढ़े हैं वे CRUD से HTTP विधियों की मैपिंग से शुरू होते हैं। अधिक को सैद्धांतिक रूप से जोड़ने की अनुमति है, लेकिन व्यावहारिकता में, नहीं। एक उदाहरण के रूप में, मैं हाल ही में Android उपकरणों के लिए PATCH को लागू करना चाहता था, लेकिन पाया कि Android PATCH को अनुमति नहीं देता है, इसलिए मैंने URI में उस प्रभाव के लिए स्पष्ट रूप से परिभाषित कार्रवाई के साथ POST का उपयोग किया। मूल रूप से, शुद्ध REST उन नौकरियों को नहीं करेगा जिनकी मुझे आवश्यकता है, इसलिए मैं उन कार्यों का उपयोग करता हूं।

— ब्रूस पाटन

4

तो @BrucePatin, आपके संस्करण "REST" में आपके पास चार सार्वजनिक विधियों के साथ एक नियंत्रक है जो GET | PUT | POST | DELETE के साथ 1 से 1 मानचित्र पर है। कुछ चौखटे ऐसा करते हैं, लेकिन यह REST नहीं है। HTTP वर्ब्स किसी दिए गए अनुरोध के शब्दार्थ के बारे में अस्पष्ट सार कथन करता है। आपको अपने अंतिम बिंदुओं को उन वर्गों में उचित रूप से मैप करना होगा। जीईटी कई अलग-अलग बिंदुओं पर मैप कर सकता है, इसलिए अन्य। वास्तव में कोई कारण नहीं है कि आप HTTP पर REST-ful JSON-RPC को लागू नहीं कर सकते।

— स्पिंकस

5

बहुत अच्छा कारण है। मैं कई दर्जन कार्रवाइयां कर सकता हूं, और पहले ही एक आम उपयोग (एंड्रॉइड) में चला गया हूं जो कि PATCH का समर्थन नहीं करता है। जो इसे ठंडा मारता है। मैं इसके बजाय नियम के कई अपवादों से निपटना चाहता हूं। सामान्य तौर पर, मैं अब केवल GET, POST और DELETE का उपयोग करूंगा। PUT उस प्रतिक्रिया के लिए अनुमति नहीं देता है जो मैं एक अपडेट ऑपरेशन पर चाहूंगा। मैं लगभग हर चीज के लिए POST का उपयोग कर रहा हूं। कैशिंग के बारे में, इसने पुराने डेटा को वापस करके कई समस्याएं पैदा की हैं। POST में पैरामीटर डालने के बारे में, ASP.NET पहले से ही इसे स्वचालित JSON ऑब्जेक्ट्स से स्वचालित रूप से हैंडल करता है।

— ब्रूस पाटन

22

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

— चंचल जेडी

29

सबसे पहले, HTTP-REST एक "प्रतिनिधित्ववादी राज्य स्थानांतरण" वास्तुकला है। इसका मतलब है कि बहुत सी दिलचस्प बातें:

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

दूसरा, HTTP-REST पूरी तरह से HTTP ("सुरक्षित" और पिछले भाग में "idempotent") के अनुरूप है, इसलिए आप HTTP पुस्तकालयों (हर मौजूदा भाषा के लिए मौजूदा) और HTTP रिवर्स परदे के पीछे का उपयोग करने में सक्षम होंगे, जो आपको देगा कोड की शून्य रेखा के साथ उन्नत सुविधाओं (कैश, प्रमाणीकरण, संपीड़न, पुनर्निर्देशन, पुनर्लेखन, लॉगिंग, आदि) को लागू करने की क्षमता।

पिछले नहीं बल्कि कम से कम, HTTP 1.1 (और REST के आविष्कारक) के डिजाइनर के अनुसार एक RPC प्रोटोकॉल के रूप में HTTP का उपयोग करना एक बहुत बड़ी त्रुटि है: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation। htm # sec_6_5_2

— Aurélien
स्रोत

1

+1 आधिकारिक, व्यक्ति-जो-के-संदर्भ के लिए पता होना चाहिए .... इसके बाद HTTP पर RPC के लिए बहस करना कठिन है, इसे हैक / काम के इर्द-गिर्द स्वीकार किए बिना ....

— RJB

9

आपने अभी 2000 से कुछ संदर्भित किया है। यह REST बनाम RPC के लिए अधिक दार्शनिक तर्क है। शब्दार्थ और RPC पैटर्न लागू करने से आप आसानी से URI को "प्रक्रिया" और इनकोडिंग पैरामीटर ... अच्छी तरह से ... पैरामीटर मान सकते हैं। या तो पैटर्न HTTP पर ठीक काम करेगा। SOAP, Rails या किसी भी अन्य पैटर्न / प्रोटोकॉल के साथ समान जो HTTP पर ओवरले किया गया है। इससे कोई फर्क नहीं पड़ता कि जब तक आप एक सुसंगत एपीआई की पेशकश नहीं करते हैं जो इसे अनुबंधित नहीं करता है।

— चंचल जेडी

औरेलिन, क्या आप बता सकते हैं, क्यों REST स्वतंत्र सॉफ़्टवेयर भागों के साथ एकीकृत करना आसान है? मेरे लिए, भले ही आप RESTful API या RPC का उपयोग करें, क्लाइंट सॉफ़्टवेयर को आपके API वार्ता प्रारूप को जानना आवश्यक है।

— एलेक्सी

1

@ अलेक्से यह तर्क सांविधिकता के सापेक्ष था। यह एक कॉफी मशीन जिसका एपीआई है एकीकृत करने के लिए आसान है CREATE CUP, एक और है कि होते हैं की तुलना में INSERT COIN, SELECT COFFEE, SELECT SUGAR, और START। दूसरे एपीआई में, क्योंकि यह मशीन की स्थिति पर निर्भर करता है, आपको प्रक्रिया कॉल के अनुक्रम के साथ बहुत सावधान रहना होगा।

— औरेलिन

1

HTTP एक RPC प्रोटोकॉल के रूप में है बाकी। तो आपकी गलत व्याख्या चौंकाने वाले तरीके से चारों ओर है।

— तिबरियू-आयनो स्टेन

24

महान जवाब - बस कुछ टिप्पणियों पर स्पष्ट करना चाहते थे। JSON-RPC का उपयोग करना त्वरित और आसान है, लेकिन जैसा कि उल्लेख किया गया है कि संसाधन और पैरामीटर कसकर युग्मित हैं और यह GET / POST का उपयोग करके क्रियाओं (api / deleteUser, api / addUser) पर भरोसा करता है, जहां-जहाँ यह शिथिल युग्मित संसाधन प्रदान करता है (एपीआई / उपयोगकर्ता) जो HTTP REST API में कई HTTP विधियों (GET, POST, PUT, PATCH, DELETE) पर निर्भर हैं। अनुभवहीन डेवलपर्स को लागू करने के लिए आरईएसटी थोड़ा कठिन है, लेकिन शैली अब काफी सामान्य जगह बन गई है और यह लंबे समय (आपके एपीआई को लंबा जीवन देने) में बहुत अधिक लचीलापन प्रदान करता है।

कसकर युग्मित संसाधनों के न होने के साथ, REST आपको एकल सामग्री-प्रकार के लिए प्रतिबद्ध होने से बचने की अनुमति देता है- इसका मतलब है कि यदि आपके ग्राहक को XML, या JSON, या यहां तक कि YAML में डेटा प्राप्त करने की आवश्यकता है - यदि आपके सिस्टम में बनाया गया हो तो सामग्री-प्रकार / हेडर स्वीकार करने वालों का उपयोग करने वालों में से किसी को भी लौटाएं।

यह आपको नई सामग्री प्रकार या क्लाइंट आवश्यकताओं का समर्थन करने के लिए अपने एपीआई को पर्याप्त लचीला बनाए रखने देता है।

लेकिन RSON को JSON-RPC से वास्तव में अलग करता है, यह ध्यान से सोचा बाधाओं की एक श्रृंखला का पालन करता है- वास्तु लचीलेपन को सुनिश्चित करता है। इन बाधाओं में यह सुनिश्चित करना शामिल है कि क्लाइंट और सर्वर एक दूसरे से स्वतंत्र रूप से विकसित होने में सक्षम हैं (आप अपने क्लाइंट के एप्लिकेशन को गड़बड़ किए बिना बदलाव कर सकते हैं), कॉल स्टेटलेस हैं (हाइपरमीडिया के माध्यम से राज्य का प्रतिनिधित्व किया जाता है), इंटरैक्शन के लिए एक समान इंटरफ़ेस प्रदान किया जाता है। एपीआई एक स्तरित प्रणाली पर विकसित किया गया है, और ग्राहक द्वारा प्रतिक्रिया अस्वीकार्य है। मांग पर कोड प्रदान करने के लिए एक वैकल्पिक बाधा भी है।

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

यह भी आप (जैसे Stormpath के रूप में) यूआरआई करने के लिए ग्राहक को निर्देशित (कुछ परिवर्तन करता है, तो अर्थ, में हाइपरमीडिया संचालित एपीआई के रूप में कुछ लचीलापन प्रदान करता है कुछ मामलों आप नकारात्मक प्रभाव के बिना यूआरआई संशोधित कर सकते हैं), जहां के रूप में आरपीसी यूआरआई के साथ होना भी आवश्यक है स्थिर। आरपीसी के साथ, आपको इन अलग-अलग यूआरआई को व्यापक रूप से दस्तावेज करने और यह समझाने की आवश्यकता होगी कि वे एक-दूसरे के संबंध में कैसे काम करते हैं।

सामान्य तौर पर, मैं कहूंगा कि REST जाने का एक तरीका है यदि आप एक एक्स्टेंसिबल, लचीले एपीआई का निर्माण करना चाहते हैं जो लंबे समय तक जीवित रहेगा। उस कारण से, मैं कहूंगा कि यह समय का 99% जाने का मार्ग है।

सौभाग्य, माइक

— माइक स्टोव
स्रोत

3

यह थोड़ा कठिन नहीं है, बल्कि बहुत अधिक कठिन है। मैं इसे 4 महीने या तो समझने की कोशिश कर रहा हूं, और अभी भी इस बात का एक अच्छा तरीका नहीं है कि एक ऐसी सेवा कैसे लिखी जाए जो http का उपयोग करने वाले HTTP पर एक बेकार RPC में विकसित न हो, और मैं अभी भी आश्वस्त नहीं हूं "REST" और जो मैंने अभी कहा

— उसके

19

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

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

यदि नहीं (उदाहरण के लिए एक एसपीएएक्स में एजेक्स फ्रंट-एंड बनाने के मामले में), मेरी पसंद आरपीसी है। विशेष रूप से JSON-RPC में, JSON स्कीमा को विवरण भाषा के रूप में संयोजित किया गया है, और उपयोग के मामले के आधार पर HTTP या Websockets पर ले जाया गया है।

JSON-RPC एक सरल और सुरुचिपूर्ण विनिर्देश है जो अनुरोध और प्रतिक्रिया को परिभाषित करता है JSON पेलोड को तुल्यकालिक या अतुल्यकालिक RPC में उपयोग किया जाता है।

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

ट्रांसपोर्ट प्रोटोकॉल (HTTP बनाम वेबसोकेट) की पसंद अलग-अलग कारकों पर निर्भर करती है, सबसे महत्वपूर्ण यह है कि आपको HTTP फीचर्स की आवश्यकता है (कैशिंग, रिवाइलेशन, सुरक्षा, बेरोजगारी, सामग्री-प्रकार, मल्टीपार्ट, ...) या क्या आपको एप्लिकेशन को इंटरचेंज करने की आवश्यकता है उच्च स्वतंत्रता पर संदेश।

अब तक यह मुद्दे पर मेरी व्यक्तिगत राय है, लेकिन अब कुछ ऐसा है जो वास्तव में उन जावा डेवलपर्स के लिए मददगार हो सकता है जो इन पंक्तियों को पढ़ रहे हैं, पिछले वर्ष के दौरान मैं जिस रूपरेखा पर काम कर रहा था, उसी प्रश्न से पैदा हुआ था जिसे आप अभी सोच रहे हैं। :

http://rpc.brutusin.org

आप यहां एक लाइव डेमो देख सकते हैं, जो कार्यात्मक परीक्षण के लिए अंतर्निहित रिपॉजिटरी ब्राउज़र दिखा रहा है (धन्यवाद JSON स्कीमा) और उदाहरण सेवाओं की एक श्रृंखला:

http://demo.rpc.brutusin.org

आशा है कि यह दोस्त की मदद करता है!

नाचो

— idelvall
स्रोत

एक दयालु आत्मा को खोजने के लिए बहुत अच्छा है! मैं यहाँ पर कुछ इसी तरह काम कर रहा हूँ: github.com/dnault/therapi-json-rpc

— dnault

:) मैं इसे

— देखूंगा

1

इससे सहमत हैं। REST CRUD API के लिए अच्छा काम करता है क्योंकि आपके पास स्पष्ट POST / GET / PUT / DELETE [PoGPuD है? ;)] मैपिंग। हालाँकि, यदि आपका API उन क्रियाओं में आराम से फिट नहीं होता है , तो JSON-RPC एक अच्छा विकल्प हो सकता है क्योंकि क्रियाएं बस मामलों को भ्रमित करने वाली हैं। तो हाँ, कौन इसका उपयोग कर रहा है और एक बड़ा कारक क्यों है।

— एलिग टेलर

1

वास्तव में - REST संज्ञाओं का राज्य है, JSON-RPC क्रिया है।

— रॉब

16

यदि आपकी सेवा केवल मॉडल और GET / POST / PUT / DELETE पैटर्न के साथ ठीक काम करती है, तो शुद्ध REST का उपयोग करें।

मैं मानता हूं कि HTTP मूल रूप से स्टेटलेस एप्लिकेशन के लिए डिज़ाइन किया गया है।

लेकिन आधुनिक, अधिक जटिल (!) वास्तविक समय (वेब) अनुप्रयोगों के लिए जहां आप वेबसोकेट्स (जो अक्सर राज्य की आवश्यकता होती है) का उपयोग करना चाहते हैं, दोनों का उपयोग क्यों नहीं करेंगे? वेबस्कैट पर JSON-RPC बहुत हल्का है, इसलिए आपको निम्नलिखित लाभ हैं:

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

जैसा कि आप केवल सर्वर साइड API डिज़ाइन कर रहे हैं, REST मॉडल को परिभाषित करने के साथ शुरू करें और बाद में आवश्यकतानुसार JSON-RPC समर्थन जोड़ें, RPC कॉल की संख्या को न्यूनतम रखते हुए।

(और कोष्ठक अति प्रयोग के लिए खेद है)

— cbix
स्रोत

15

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

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

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

इस वजह से, आरपीसी आज मेरे लिए बहुत सरल और अधिक प्राकृतिक लगता है। हालांकि मैं वास्तव में याद करता हूं कि एक सुसंगत ढांचा है जो आरपीसी सेवाओं को लिखना आसान बनाता है जो कि आत्म-वर्णन करने वाले और इंटरऑपरेबल हैं। इसलिए मैंने RPC को अपने लिए आसान बनाने के लिए नए तरीकों के साथ प्रयोग करने के लिए अपनी खुद की परियोजना बनाई और शायद किसी और को यह उपयोगी लगती है, भी: https://github.com/aheck/reflectrpc

— Ahe
स्रोत

OpenRPC की जाँच करें, इसे "RPC सेवाओं को लिखने में आसान जो स्वयं-वर्णन करने योग्य और अंतर-लिखने योग्य हैं" के लिए आपकी आवश्यकता को हल करना चाहिए

— बेल्फोर्डेज़

11

रिचर्डसन परिपक्वता मॉडल के अनुसार , प्रश्न REST बनाम RPC नहीं है , लेकिन REST कितना है ?

इस दृष्टि से, REST मानक के अनुपालन को 4 स्तरों में वर्गीकृत किया जा सकता है।

स्तर 0: कार्यों और मापदंडों के संदर्भ में सोचें। जैसा कि लेख बताता है, यह अनिवार्य रूप से JSON-RPC के बराबर है (लेख इसे XML-RPC के लिए बताता है, लेकिन दोनों के लिए समान तर्क हैं)।
स्तर 1: संसाधनों के संदर्भ में सोचें। संसाधन के लिए प्रासंगिक सब कुछ उसी URL का है
स्तर 2: HTTP क्रियाओं का उपयोग करें
स्तर 3: हेटोस

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

— छोटा सा अंतराल
स्रोत

1

+1 के स्तर 0, 1 और 2 के लिए। हालाँकि मैंने कभी भी HATEOS का सफल क्रियान्वयन नहीं देखा है, लेकिन दो बार असफल प्रयासों को देखा है।

— mjhm

8

JSON आरपीसी क्यों:

REST API के मामले में, हमें प्रत्येक कार्यक्षमता / विधि के लिए एक नियंत्रक को परिभाषित करना होगा जिसकी हमें आवश्यकता हो सकती है। परिणामस्वरूप यदि हमारे पास 10 विधियाँ हैं जो हम एक ग्राहक तक पहुँचना चाहते हैं, तो हमें किसी विशेष विधि के लिए ग्राहक के अनुरोध को इंटरफ़ेस करने के लिए 10 नियंत्रक लिखने होंगे।

एक अन्य कारक है, भले ही हमारे पास प्रत्येक विधि / कार्यक्षमता के लिए अलग-अलग नियंत्रक हों, ग्राहक को POST या GET का उपयोग करने के लिए तार को याद रखना होगा। इससे चीजें और उलझ जाती हैं। डेटा भेजने के लिए शीर्ष पर, किसी को POST का उपयोग करने पर अनुरोध के प्रकार को सेट करना होगा।

JSON RPC के मामले में, चीजें बहुत सरल हो जाती हैं क्योंकि ज्यादातर JSONRPC सर्वर POST HTTP विधियों पर काम करते हैं और सामग्री प्रकार हमेशा अनुप्रयोग / json होता है। यह क्लाइंट साइड पर उचित HTTP विधि और सामग्री सेटिंग्स का उपयोग करने के लिए याद रखने का लोड बंद करता है।

एक को अलग-अलग तरीकों / कार्यात्मकताओं के लिए अलग-अलग नियंत्रक बनाने की ज़रूरत नहीं होती है जो सर्वर क्लाइंट को उजागर करना चाहता है।

क्यों:

आपके पास अलग-अलग कार्यक्षमता के लिए अलग-अलग URL हैं जो सर्वर क्लाइंट पक्ष को उजागर करना चाहता है। परिणामस्वरूप, आप इन url को एम्बेड कर सकते हैं।

इनमें से अधिकांश बिंदु बहस योग्य हैं और पूरी तरह से एक व्यक्ति की आवश्यकता पर निर्भर करते हैं।

— उमर फारूक
स्रोत

3

मुझे लगता है, हमेशा की तरह, यह निर्भर करता है ...

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

इसलिए, जब आप एक सिंगल पेज वेब ऐप लिखते हैं, जिसमें बैकएंड पर बात करनी होती है, तो मुझे लगता है कि REST रास्ता बहुत जटिल है। इस स्थिति में आपको दीर्घकालिक संगतता के बारे में चिंता करने की ज़रूरत नहीं है क्योंकि ऐप और एपीआई एक साथ विकसित हो सकते हैं।

मैंने एक बार REST के साथ एक सिंगल पेज वेब ऐप के लिए शुरुआत की थी, लेकिन वेब ऐप और सर्वर के बीच बारीक बारीक कमांड ने मुझे तुरंत पागल कर दिया। क्या मुझे इसे एक पथ पैरामीटर के रूप में एन्कोड करना चाहिए? शरीर में? एक क्वेरी पैरामीटर? एक हेडर? URL / Verb / रिस्पॉन्स डिज़ाइन के बाद मुझे फिर जावास्क्रिप्ट में इस गड़बड़ी को कोड करना पड़ा, जावा में डिकोडर और फिर वास्तविक विधि को कॉल करना। हालाँकि इसके लिए बहुत सारे उपकरण हैं, लेकिन आपके डोमेन कोड में किसी भी HTTP शब्दार्थ को नहीं प्राप्त करना वास्तव में मुश्किल है, जो वास्तव में बुरा अभ्यास है। (सामंजस्य)

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

इसलिए मैंने सिंगल पेज वेबऐप के लिए REST से JSON-RPC में स्विच किया। aI ने एक छोटी लाइब्रेरी विकसित की है जो सर्वर पर जावा इंटरफेस को इनकोड करती है और इसे ब्राउजर में भेजती है। ब्राउज़र में इसने एप्लिकेशन कोड के लिए एक प्रॉक्सी बनाई, जिसने प्रत्येक फ़ंक्शन के लिए एक वादा वापस किया।

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

— पीटर क्रिएन्स
स्रोत

1

इस जवाब ने मुझे ग्राफक्यूएल और जेएसएन-आरपीसी के बीच समानता का एहसास कराया और क्यों ग्राफ्स के लिए ग्राफकलाइन एक लोकप्रिय विकल्प बन रहा है।

— डेनिस

OpenRPC OpenAPI / स्वैगर के बराबर है, लेकिन JSON-RPC के लिए

— बेलफ़ोर्डेज़

1

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

— dtoux
स्रोत

2

REST एक वास्तुशिल्प शैली है न कि प्रोटोकॉल-निर्भर।

— मार्क सिडैड

4

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

— dtoux

1

वेब एप्लिकेशन के लिए API विकसित करने के लिए REST और JSON-RPC के बीच JSON-RPC चुनना बेहतर होगा जिसे समझना आसान हो। JSON-RPC को प्राथमिकता दी जाती है क्योंकि विधि कॉल और संचार के लिए इसकी मैपिंग को आसानी से समझा जा सकता है।

सबसे उपयुक्त दृष्टिकोण चुनना बाधाओं या प्रमुख उद्देश्य पर निर्भर करता है। उदाहरण के लिए, जहां तक प्रदर्शन एक प्रमुख विशेषता है, JSON-RPC (उदाहरण के लिए, उच्च प्रदर्शन कम्प्यूटिंग) के लिए जाना उचित है। हालांकि, यदि मुख्य उद्देश्य अज्ञेय होना है ताकि दूसरों को अनुमान लगाने के लिए एक सामान्य इंटरफ़ेस पेश किया जा सके, तो आरईएसटी के लिए जाना उचित है। यदि आप दोनों लक्ष्यों को प्राप्त करने की आवश्यकता है, तो दोनों प्रोटोकॉल को शामिल करना उचित है।

तथ्य यह है कि वास्तव में JSON-RPC से REST को विभाजित करता है, यह ध्यान से सोचा बाधाओं की एक श्रृंखला को पार करता है- वास्तु लचीलेपन की पुष्टि करता है। यह सुनिश्चित करने में बाधाएं आती हैं कि क्लाइंट और सर्वर एक-दूसरे से स्वतंत्र रूप से बढ़ने में सक्षम हैं (क्लाइंट के आवेदन के साथ गड़बड़ किए बिना बदलाव किए जा सकते हैं), कॉल स्टेटलेस हैं (राज्य को हाइपरमीडिया कहा जाता है), एक समान इंटरफ़ेस बातचीत के लिए पेश किया जाता है, एपीआई एक स्तरित प्रणाली (हॉल, 2010) पर उन्नत है। JSON-RPC तेजी से और उपभोग करने में आसान है, हालांकि उल्लिखित संसाधनों के साथ-साथ मापदंडों को कसकर युग्मित किया गया है और यह GET / POST का उपयोग करके क्रियाओं (api / addUser, api / deleteUser) पर निर्भर होने की संभावना है, जबकि कीट शिथिल युग्मित संसाधनों (एपीआई) को बचाता है / उपयोगकर्ता) एक HTTP में। REST API कई HTTP विधियों जैसे GET, PUT, POST, DELETE, PATCH पर निर्भर करता है।

JSON (जावास्क्रिप्ट ऑब्जेक्ट नोटेशन के रूप में चिह्नित) एक हल्के डेटा-इंटरचेंज प्रारूप होने के नाते, मनुष्यों के साथ-साथ पढ़ने के लिए भी आसान है। यह मशीनों को पार्स और उत्पन्न करने के लिए परेशानी मुक्त है। JSON एक पाठ प्रारूप है, जो पूरी तरह से भाषा स्वतंत्र है, लेकिन वह परंपराएं हैं जो भाषाओं के परिवार के प्रोग्रामर से परिचित हैं, जिनमें C #, C, C ++, Java, पर्ल, जावास्क्रिप्ट, पायथन और कई अन्य शामिल हैं। ऐसे गुण JSON को एक संपूर्ण डेटा-इंटरचेंज भाषा बनाते हैं और चुनने के लिए एक बेहतर विकल्प है।

— SinghKunal
स्रोत

"यह मशीनों को पार्स करने के लिए परेशानी मुक्त है" - मैंने बहुत सारे टूटे हुए JSON (जैसे पेलोड में

— अनसैप्ड

1

गलत सवाल: एक ऐसा मैनिचियन लगाया जाता है जो मौजूद नहीं है!

आप "कम क्रिया" (कोई विधि ) के साथ JSON-RPC का उपयोग कर सकते हैं और Sendo आईडी, पैरामीटर, त्रुटि कोड और चेतावनी संदेशों के लिए आवश्यक न्यूनतम मानकीकरण को संरक्षित कर सकते हैं । JSON-RPC मानक यह नहीं कहता कि "आप REST नहीं हो सकते", केवल यह कहें कि बुनियादी जानकारी कैसे पैक करें।

"बाकी JSON-RPC" मौजूद है ! सरल और ठोस अनुबंध के साथ न्यूनतम सूचना पैकिंग के लिए "सर्वोत्तम प्रथाओं" के साथ आरईएसटी है।

उदाहरण

( इस उत्तर और उपदेशात्मक संदर्भ से)

आरईएसटी के साथ काम करते समय, यह आमतौर पर संसाधनों के संदर्भ में सोचकर शुरू करने में मदद करता है। इस मामले में, संसाधन केवल "बैंक खाता" नहीं है, बल्कि यह उस बैंक खाते का एक लेनदेन है ... लेकिन JSON-RPC "विधि" पैरामीटर को बाध्य नहीं करता है, सभी समापन बिंदु के "पथ" द्वारा एन्कोड किए गए हैं।

बाकी जमा के साथ POST /Bank/Account/John/TransactionJSON अनुरोध के साथ {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}।
JSON प्रतिक्रिया कुछ इस प्रकार हो सकती है{"jsonrpc": "2.0", "result": "sucess", "id": 12}
बाकी को वापस लेने के साथ POST /Bank/Account/John/Transaction... समान।
... GET /Bank/Account/John/Transaction/12345@13... यह उस सटीक लेनदेन का JSON रिकॉर्ड लौटा सकता है (जैसे आपके उपयोगकर्ता आमतौर पर अपने खाते पर डेबिट और क्रेडिट का रिकॉर्ड चाहते हैं)। कुछ इस प्रकार है {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}। (REST) GET अनुरोध के बारे में कन्वेंशन में "@id" द्वारा आईडी का एनकोड शामिल हो सकता है, इसलिए किसी JSON को भेजने की आवश्यकता नहीं है, लेकिन अभी भी प्रतिक्रिया पैक में JSON-RPC का उपयोग कर रहा है।

— पीटर क्रस
स्रोत

इन्हें भी देखें stackoverflow.com/a/13952665/287948

— पीटर क्रूस

0

यदि आप संसाधनों का अनुरोध करते हैं, तो डिज़ाइन द्वारा RESTful API बेहतर है। यदि आप सरल सीआरयूडी के अलावा बहुत सारे मापदंडों और जटिल तरीकों के साथ कुछ जटिल डेटा का अनुरोध करते हैं, तो आरपीसी जाने का सही तरीका है।

— एड्रियन लियू
स्रोत

यह विषय का एक बहुत बड़ा ओवर-सरलीकरण है। क्यों, विशेष रूप से, यह "डिजाइन द्वारा बेहतर" है? JSON-RPC जितना चाहें उतना सरल या जटिल हो सकता है, और इसलिए "बहुत सारे मापदंडों और जटिल तरीकों के लिए" बेहतर होने का तर्क भी गलत है। यह इस मामले में बेहतर या बुरा नहीं है।

— बेलफ़ोर्ड

इससे कोई फर्क नहीं पड़ता कि RPC डेटा को क्रमबद्ध करने के लिए JSON या प्रोटोबॉफ़ या XML का उपयोग करती है। जैसा कि मैंने कहा था कि प्रमुख बिंदु एपीआई है। मेरा मतलब यह नहीं है कि सभी मामलों में एक दूसरे से बेहतर है। लेकिन मुझे लगता है कि जब आप दो कार्यान्वयनों के बीच चयन कर रहे हैं तो पैरामीटर और तरीके मायने रखते हैं। यदि वे सरल हैं, तो Restful API को अधिकांश प्रोग्रामर अच्छी तरह से समझ जाते हैं और आप आसानी से http अनुरोध का निर्माण कर सकते हैं। यदि वे जटिल हैं, तो RPC ऐसे API को व्यक्त करने में अधिक सक्षम है, और आपकी IDE और कंपाइलर इसमें आपकी मदद कर सकते हैं।

— एड्रियन लियू

-1

मैं आरपीसी प्रोटोकॉल के लिए vdata का उपयोग करता हूं: http://vdata.dekuan.org/

1, PHP और जावास्क्रिप्ट दोनों ठीक हैं। 2, क्रॉस-ऑरिजनल रिसोर्स शेयरिंग (कोर) कॉल अभी भी ठीक है।

— लियू किक्सिंग
स्रोत