आज आरईएसटी पर एक दिलचस्प डेमो में भाग लिया, हालांकि, मैं एक कारण के बारे में नहीं सोच सकता था (न ही एक प्रस्तुत किया गया था) क्यों आरईएसटी किसी भी तरह से एसओएपी आधारित सेवाओं के ढेर के उपयोग और कार्यान्वित करने के लिए बेहतर या सरल है।एसओएपी आधारित सेवाओं के बजाय आरईएसटी का उपयोग क्यों करेगा?
कुछ कारण क्या हैं "वास्तविक दुनिया" में से कोई भी एसओएपी आधारित सेवाओं के बजाय आरईएसटी का उपयोग क्यों करता है?
कम भूमि के ऊपर (कोई सोप लिफाफा हर कॉल रैप करने के लिए)
कम दोहराव (HTTP पहले से ही हटाने जैसे कार्य का प्रतिनिधित्व करता है, डाल, मिलता है, आदि है कि अन्यथा एक सोप लिफाफा में प्रतिनिधित्व करने की है)।
अधिक मानकीकृत - HTTP संचालन अच्छी तरह से समझा जाता है और लगातार संचालित होता है। कुछ SOAP कार्यान्वयन मुश्किल हो सकता है।
अधिक मानव पठनीय और टेस्टेबल (केवल एक ब्राउज़र के साथ SOAP का परीक्षण करने के लिए कठिन)।
एक्सएमएल का उपयोग करने की आवश्यकता नहीं है (अच्छी तरह से आपको एसओएपी के लिए नहीं होना चाहिए, लेकिन यह शायद ही कभी समझ में आता है क्योंकि आप पहले से ही लिफाफे के पार्सिंग कर रहे हैं)।
पुस्तकालयों ने SOAP (प्रकार) को आसान बना दिया है। लेकिन जैसा कि मैंने नोट किया है, नीचे आप बहुत सारी अनावश्यकता को दूर कर रहे हैं। हां सिद्धांत में एसओएपी अन्य ट्रांसपोर्टों पर जा सकता है ताकि समान परत करने वाली परत के ऊपर सवारी से बचने के लिए, लेकिन हकीकत में बस आपके द्वारा किए गए सभी एसओएपी काम के बारे में HTTP पर है।
मैं यह जोड़ना चाहता हूं कि इंटर-प्लेटफार्म एसओएपी संचार एक पिटा भी हो सकता है (एसओएपी के बिंदु का वह हिस्सा नहीं था?!?)। –
HTTP बुनियादी ढांचे के साथ भी बढ़िया काम करना - उदा।अंतिम संशोधित और etags –
के उपयोग के साथ जीईटी आक्रामक रूप से कैश किए जाते हैं, आपकी सेवाओं के लिए सार्वभौमिक ग्राहक प्रदान करने के लिए वेब ब्राउज़र के साथ काम करना भी मदद करता है :) –
आरईएसटी मूल रूप से वेब सेवाओं को लागू करने का एक तरीका है। यह उन वेब सेवाओं से पूछने के लिए HTTP का सही उपयोग करने का एक तरीका है जिसे आप हिट करने का प्रयास कर रहे हैं।
http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer
REST के पास HTTP के साथ कुछ लेना देना नहीं है, और पूरी तरह से प्रोटोकॉल-स्वतंत्र है। हालांकि यह कुछ प्रकार की संसाधन-केंद्रित वेब सेवाओं के लिए उपयुक्त है। – aehlke
मुझे लगता है तब होगी जब आप कहते हैं कि "वेब सेवाओं" क्या आपका मतलब है कि मानकों के सोप और WS- * सेट। (अन्यथा, मुझे लगता है कि बाकी सेवाओं "वेब सेवाओं" कर रहे हैं लोगों का तर्क हो सकता है।)
विहित तर्क यह है कि बाकी सेवाओं वेब के डिजाइन करने के लिए एक करीब मैच हो रहा है - जो है, HTTP के डिजाइन और संबद्ध बुनियादी ढांचे । इस प्रकार, एक आरईएसटी सेवा का उपयोग मौजूदा वेब टूल्स और तकनीकों के साथ अधिक संगत होगा।
बेशक, एक बार जब आप विनिर्देशों में ड्रिल करते हैं, तो आप पाते हैं कि दोनों दृष्टिकोणों में विभिन्न परिदृश्यों में ताकत है। क्या यह उन विशिष्टताओं में से एक है जिन्हें आप रुचि रखते हैं?
RESTful सेवाएं SOAP आधारित (नियमित) सेवाओं से उपभोग करने के लिए बहुत आसान हैं। इसका कारण यह है कि आरईएसटी सामान्य HTTP अनुरोधों पर आधारित है जो अनुरोध के प्रकार से प्राप्त होने के इरादे को सक्षम बनाता है (GET = retrive, POST = लिखें, DELETE = निकालें, आदि ...) और पूरी तरह से स्टेटलेस है। दूसरी तरफ आप तर्क दे सकते हैं कि यह कम लचीला है क्योंकि यह एक संदेश लिफाफा की अवधारणा से दूर है जिसमें अनुरोध संदर्भ शामिल है।
मेरे अनुभव में एसओएपी को उद्यम के भीतर सेवाओं के लिए प्राथमिकता दी गई है और सार्वजनिक एपीआई के रूप में उजागर सेवाओं के लिए आरईएसटी को प्राथमिकता दी गई है।
.NET ढांचे में डब्ल्यूसीएफ जैसे टूल्स के साथ आरईएसटी या एसओएपी के रूप में सेवा को लागू करना बहुत छोटा है।
कुछ प्रासंगिक पढ़ने:
मेरी समझ यह है कि वेब सेवा विधियों का पर्दाफाश करने के लिए कक्षाएं उत्पन्न करने के लिए डब्ल्यूएसडीएल फाइलों का उपयोग किया जा सकता है। निश्चित रूप से यह सेवाओं की खपत को एक समारोह को कॉल करने जितना आसान बनाता है? क्या आप अपने विचार को और कुछ और बता सकते हैं। –
हॉवर्ड मई: मान लीजिए कि आप केवल आदिम डेटाटाइप का उपयोग करके कार्यों को कॉल करते हैं, यह निश्चित रूप से सच है। लेकिन उस स्थिति में आप बिल्कुल तर्क नहीं दे सकते कि एसओएपी आराम से आसान है। यदि आपके पास जटिल डेटाटाइप हैं, तो डब्ल्यूएसडीएल प्रसंस्करण एक ही डब्ल्यूएस स्टैक्स के साथ दो मशीनों के बीच ठीक काम कर सकता है। लेकिन जैसे ही आप ढेर मिश्रण करते हैं, आपको अनिवार्य रूप से समस्याएं होंगी। एक बार जब आप असंगतताओं को डीबग करने के लिए हाथ से डब्लूएसडीएल में खोदना चाहते हैं तो यह इतना आसान हो जाता है। –
2014 में, लगभग हर मंच, यहां तक कि प्राचीन भी, डब्लूएसडीएल का समर्थन करते हैं। प्रॉक्सी कक्षाएं एपीआई का उपयोग बेहद सरल बनाती हैं। हम एक पुश सेवा लागू कर रहे हैं और मैं आरईएसटी पर विचार कर रहा हूं, लेकिन मुझे वास्तव में किसी भी लाभ को देखने में परेशानी हो रही है। – JohnOpincar
गॉट रॉय फील्डिंग की सबसे उत्कृष्ट dissertation विषय पर पढ़ने के लिए। वह एक उत्कृष्ट मामला बनाता है और निश्चित रूप से वे अपने समय से पहले लिखा था (2000)।
Steve Vinoski's blog और उनके latest articles निश्चित रूप से मूल्यवान हैं। वह एक पूर्व कोर्बा गुरु है, जिसने शायद इस विषय पर माइक हेनिंग, "Advanced CORBA® Programming with C++" के साथ सबसे अच्छी किताब लिखी थी। हालांकि, उसके बाद से उसने अपने ग्राहक/सर्वर तरीकों की त्रुटि देखी है, और अब आरईएसटी द्वारा कसम खाता है।
यह बहुत सरल और पतला है। आप http verb के माध्यम से ब्राउज़र के साथ ऐसा कर सकते हैं: प्राप्त करें। मुझे कोई ब्राउज़र नहीं मिला है जो आसानी से जेनेरिक http POST अनुरोध मैन्युअल रूप से कर सकता है
चेकआउट फिडलर। यह ब्राउज़र नहीं है लेकिन कोड के बिना HTTP पोस्ट का निर्माण करने का यह एक शानदार तरीका है। http://fiddler2.com/fiddler2/ –
मैं आमतौर पर चार्ल्स के साथ मौजूदा अनुरोध को संशोधित करने के साथ करता हूं। मेरे पास फिडलर भी है। –
REST कार्यान्वयन-अज्ञेयवादी और अधिक पारदर्शी है, और यह सार्वजनिक एपीआई के लिए बहुत अच्छा बनाता है, खासकर फ़्लिकर, अमेज़ॅन या डिग जैसे बड़ी वेबसाइटों के लिए अपने एपीआई का विपणन उपकरण के रूप में उपयोग कर रहे हैं और वास्तव में लोगों को अपने डेटा का उपभोग करना चाहते हैं। वे नौसिखिया डेवलपर्स के हाथों को पकड़ने के लिए चाहते हैं जो अपनी पसंद की छोटी गाड़ी एसओएपी लाइब्रेरी की अपनी स्क्रिप्टिंग भाषा डीबग करने की कोशिश कर रहे हैं।
बनाम एसओएपी और डब्लूएसडीएल, जो आंतरिक अनुप्रयोगों के लिए बेहतर हैं, जहां आपके पास ड्रॉप-इन पुस्तकालय हैं और दोनों सिरों पर सुप्रसिद्ध लोग हैं। (और आपको शायद इंटरनेट-स्केल लोड-बैलेंसिंग, एचटीटीपी कैशिंग इत्यादि जैसी चीजों की परवाह नहीं है) फिर आपको एपीआई मिलती हैं जो स्वयं दस्तावेज हैं, टाइप प्रकार आदि को शून्य काम के साथ।
एक अच्छा जवाब है, लेकिन मैं असहमत हूं कि एसओएपी का मतलब है कि आपके पास इंटरनेट-स्केल लोड-बैलेंसिंग नहीं हो सकता है। – HDave
REST कैश होने के लिए आपके गैर-उत्परिवर्ती संचालन (जो आम तौर पर जीईटी क्रिया का उपयोग करते हैं) की अनुमति देता है। यही है, क्लाइंट द्वारा कैश किया गया है और/या प्रॉक्सी द्वारा कैश किया गया है। यह एक बड़ी जीत हो सकती है!
यह बस 'HTTP का सही उपयोग कर रहा है,' और REST नहीं है। – aehlke
ओवरहेड अच्छा आर्किटेक्चर के रूप में महत्वपूर्ण नहीं है।
REST एक प्रोटोकॉल नहीं है यह एक वास्तुकला है जो अच्छी स्केलेबल डिज़ाइन को प्रोत्साहित करती है। इसे अक्सर चुना जाता है क्योंकि आरपीसी में बहुत अधिक स्वतंत्रता आसानी से खराब डिजाइन का कारण बन सकती है।
अन्य कारण HTTP पर रीस्टफुल प्रोटोकॉल की अनुमानित लागत है क्योंकि यह मौजूदा प्रौद्योगिकियों (मुख्य रूप से प्रॉक्सी) का लाभ उठा सकता है। आरपीसी प्रारंभिक लागत काफी कम है लेकिन लोड लोड तीव्रता के साथ यह काफी बढ़ता जा रहा है।
यहां एक डेटा बिंदु है: अमेज़ॅन अपने एपीआई को आरईएसटी और एसओएपी प्रारूपों में प्रदान करता है और 85% उपयोग आरईएसटी है।
आरईएसटी लागू करना आसान है, समझने में आसान और उच्च प्रदर्शन।
क्या आपके पास अपने "उच्च प्रदर्शन" कथन के लिए कोई संदर्भ है? –
आपको 85% उपयोग कहां मिला? यह जानना बहुत अच्छा है (अगर मैं सबूत देख सकता हूं) – schmoopy
मैन्युअल रूप से एक एपीआई विनिर्देश, प्रिंटिंग पेज इत्यादि पढ़ना "राइट क्लिक, सर्विस रेफरेंस जोड़ें" से लागू करना आसान है? (वीएस -2010) – BlueChippy
वेब सेवाओं द्वारा आप एसओएपी शैली की वेब सेवाओं का जिक्र कर रहे हैं? क्योंकि जहां तक मुझे पता है कि आपके पास रीस्टफुल वेब सेवाएं भी हो सकती हैं। –