2012-10-31 18 views
6

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

http://xyz.com/?request= {"जेसनआरपीसी": "2.0", "आईडी": 1, "विधि": "getProfile", "params": { "id": "एक्स"}}

या इसे इस बाकी का उपयोग कर की तरह होना चाहिए -

http://api.xyz.com/X

धन्यवाद

+1

यहां आपके पास तुलना है http://stackoverflow.com/questions/1098473/rest-vs-rpc – Chuidiang

+0

यदि आप आरपीसी एसओएपी का उपयोग करना चाहते हैं। अन्यथा आरईएसटी। –

उत्तर

20

"सेवा" बनाम "एपीआई" एक सुंदर अस्पष्ट सवाल है। अक्सर, दो शब्द एक दूसरे के लिए उपयोग किया जाता है। "आरईएसटी" बनाम "आरपीसी" व्याख्या करना थोड़ा आसान है।

आमतौर पर आरईएसटी के साथ, एक यूआरएल एक विशिष्ट संसाधन का प्रतिनिधित्व करता है जैसे कि "उपयोगकर्ता", एक "खाता", आदि .. आमतौर पर, आप HTTP विधियों POST/GET का उपयोग कर इन संसाधनों को बना/पुनर्प्राप्त/अद्यतन/हटा सकते हैं/PUT/हटाएँ। उपयोगकर्ता 1125 के लिए प्रोफ़ाइल का अद्यतन करने के लिए आप निम्नलिखित भेज सकते हैं:

POST /user/1125 HTTP/1.1 
Host: wherever.com 
Content-type: application/x-www-form-urlencoded 

firstName=Davey&lastName=Jones&email=dj%40thebrineydeep.com 

कुछ भी आप उपयोगकर्ता 1125 के साथ करना चाहता था, आप एक ही URL से एक अनुरोध भेजना होगा। इस विचार के अपवाद और रूप हैं, लेकिन यह इसका क्रूक्स है।

आरपीसी सेवाएं केवल एक फ़ंक्शन लाइब्रेरी का उपयोग करने की तरह है, जो एक विशिष्ट यूआरएल से जुड़ी है। आपके पास यूआरएल /services/json से जुड़े सभी संबंधित कार्यों का पूरा समूह हो सकता है। तो अगर आप पुराने डेवी जोन्स के लिए प्रोफ़ाइल बदलना चाहते हैं, क्या तुम करोगी:

POST /services/json HTTP/1.1 
Host: wherever.com 
Content-type: application/json 

{ "jsonrpc": "2.0", 
    "id": 1, 
    "method": "setProfile", 
    "params": [ 1125, 
    { "firstName": "Davey", 
     "lastName": "Jones", 
     "email": "[email protected]" 
    } 
    ] 
} 

मैं व्यक्तिगत रूप से JSON-RPC की तरह बेहतर है क्योंकि:

  • मैं कोशिश करते हैं और सभी को फिट करने के लिए की जरूरत नहीं है मेरी फ़ंक्शन किसी प्रकार के संसाधन-से-यूआरएल मैपिंग में कॉल करता है जो
  • नहीं समझ सकता है हम API त्रुटियों को इंगित करने के लिए HTTP प्रतिक्रिया कोड को अधिभारित करने का प्रयास नहीं करते हैं। प्रत्येक अनुरोध 200 प्रतिक्रिया देता है (जब तक कोई सर्वर त्रुटि न हो) और आप प्रतिक्रिया निकाय से जानते हैं कि आपको कोई त्रुटि मिली है या नहीं। JSON-RPC त्रुटियों की स्थिति के बारे में स्पष्ट होने पर विशेष रूप से अच्छा है।क्योंकि

कभी कभी बाकी बेहतर है:

  • कभी कभी संसाधन करने के लिए यूआरएल मानचित्रण वास्तव में अच्छी तरह से फिट बैठता है
  • यह अधिक सहज ज्ञान युक्त है तीसरे पक्ष को समझने के लिए
  • यह के लिए एक सरल मॉडल प्रदान करता है बस आसानी से पहचाना गया जानकारी

मुझे नहीं लगता कि कोई भी कोड कोड करना आसान है।

संपादित मैं बाकी उदाहरण JSON के बजाय अधिक आम रूप एन्कोड डेटा का उपयोग करने के लिए बदल दिया। लेकिन निश्चित रूप से आप आरईएसटी के साथ अपने पसंदीदा डेटा प्रारूप को निर्दिष्ट कर सकते हैं। यह पत्थर में नक्काशीदार नहीं है।

+0

उत्तर के लिए धन्यवाद .. क्या यह आरपीसी सेवाओं के आस-पास "रीस्ट रैपर" बनाने के लिए समझ में आता है ... जैसे कि आप उपयोगकर्ता प्रोफ़ाइल "user1" तक पहुंच रहे हैं तो उपयोगकर्ता टाइप करेगा - "http://xyz.com/user1 ".. यह आईडी" user1 "के साथ संसाधन प्राप्त करने के लिए आंतरिक रूप से आरपीसी-सेवा को कॉल करेगा ?? – Fox

+0

यह करने योग्य है, बशर्ते आपके पास REST <-> RPC से आसान मैपिंग हो। फिर भी, यह अतिरिक्त काम है। आपको खुद से पूछना होगा कि आपको इससे क्या हासिल करना है। मैं आमतौर पर सिर्फ एक या दूसरे के साथ जाऊंगा। – slashingweapon

0

आपका बाकी URL आपके JSON-RPC अनुरोध के बराबर हो।

कम से कम यह http://api.example.org/getProfile?id=X

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

यह वास्तव में कोई फर्क नहीं पड़ता कि आप क्या उपयोग करते हैं - जब तक कि आप सॉफ़्टवेयर के साथ अनुभव न करें या अनुभव न करें जो आपको एक या दूसरे समाधान को दूसरे की तुलना में अधिक तेज़ी से बनाने में सहायता करता है।

संबंधित मुद्दे