2010-02-18 16 views
15

यह एसओएपी जैसी अन्य वेब सेवाओं से अलग वेब सर्विसेज को अलग करता है?आराम से बनाम अन्य वेब सेवाएं

+0

संभावित डुप्लिकेट [हमें रीस्टफुल वेब सेवाओं की आवश्यकता क्यों है?] (Http://stackoverflow.com/questions/1368014/why-do-we-need-restful-web-services) – bummi

उत्तर

28

वेब सेवाओं पर बहस किसी भी तरह से पूरा नहीं है, लेकिन कुछ तत्व हैं जो खड़े हैं।

विश्वसनीय वेब सेवाएं वेब सेवाओं का 'परिवार' है। कुछ इसे एक वास्तुकला कहते हैं।

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

एक पूरी तरह से पुनर्स्थापित वेब सेवा के लिए केवल अनुरोधित कार्रवाई का वर्णन करने के लिए यूआरएल और HTTP क्रिया की आवश्यकता होती है ... शरीर डेटा आमतौर पर अनुरोधित कार्रवाई में शामिल होने के लिए एक पेलोड होता है ... इसे अनुरोधित कार्रवाई

को निर्देशित नहीं करना चाहिए

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

वे वेब सेवाओं को लागू करने के दो बहुत ही अलग तरीके हैं। यदि आप "कौन सा बेहतर है" सवाल पूछते हैं तो आपको शायद दोनों तरफ से मजबूत राय मिलेंगी। मेरा सुझाव है कि आप आगे की जांच करें और अपना मन बना लें।

12

RESTful वेब सेवा (जिसे एक विश्वसनीय वेब एपीआई भी कहा जाता है) HTTP और आरईएसटी के सिद्धांतों का उपयोग करके लागू एक सरल वेब सेवा है। इस तरह की एक वेब सेवा संसाधनों के संग्रह के बारे में सोचा जा सकता है। इस तरह के एक वेब सेवा की परिभाषा के रूप में तीन पहलुओं को शामिल के बारे में सोचा जा सकता है:

  • वेब सेवा के लिए आधार URI, जैसे http://example.com/resources/ रूप
  • वेब सेवा के द्वारा समर्थित डेटा के MIME प्रकार। यह अक्सर जेएसओएन, एक्सएमएल या वाईएएमएल है लेकिन यह कोई अन्य वैध एमआईएम प्रकार हो सकता है।
  • HTTP विधियों का उपयोग कर वेब सेवा द्वारा समर्थित संचालन का सेट (उदा। पोस्ट, प्राप्त करें, पुट या हटाएं)।

सोप, मूल रूप से सिम्पल ऑब्जेक्ट एक्सेस प्रोटोकॉल के रूप में परिभाषित, कंप्यूटर नेटवर्क में वेब सेवा के कार्यान्वयन में संरचित जानकारी का आदान प्रदान के लिए एक प्रोटोकॉल विनिर्देश है। यह अपने संदेश प्रारूप के रूप में एक्स्टेंसिबल मार्कअप लैंग्वेज (एक्सएमएल) पर निर्भर करता है, और आमतौर पर संदेश बातचीत और संचरण के लिए अन्य एप्लिकेशन लेयर प्रोटोकॉल (सबसे विशेष रूप से रिमोट प्रक्रिया कॉल (आरपीसी) और HTTP) पर निर्भर करता है। यह XML आधारित प्रोटोकॉल तीन हिस्से होते हैं: - जो परिभाषित करता है क्या संदेश में है और यह कैसे कार्रवाई करने के लिए -

  • एक लिफाफा, आवेदन से परिभाषित डेटाटाइप्स के उदाहरण व्यक्त करने के लिए
  • एन्कोडिंग नियमों का एक सेट
  • और प्रक्रिया कॉल और प्रतिक्रियाओं का प्रतिनिधित्व करने के लिए एक सम्मेलन।

संदर्भ:

वैसे, एक सरल गूगल खोज आप के लिए उत्तर प्रदान कर सकता है ...

+0

-1 त्वरित यात्रा विकी, एह। मुझे यकीन नहीं है कि लोगों को कट-एन-चिपकाने वाले उत्तरों के बारे में मुझे कैसा लगता है। Http://en.wikipedia.org/wiki/Representational_State_Transfer का संदर्भ भी नहीं। किंडा वह समय बनाता है जब मैंने बेकार खर्च किया था। संदर्भों के लिए –

+0

+2। –

2

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

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

मुझे लगता है कि वेब सेवा विकास के इन दोनों दृष्टिकोणों में उनकी जगह है। AJAX आवश्यकताओं के लिए जिन्हें किसी भी जटिल की आवश्यकता नहीं है, मैं एक HTTP हैंडलर (एएसपी.नेट) के रूप में लागू करना चाहता हूं। कुछ भी जो किसी अन्य एप्लिकेशन से या एक ही ऐप के भीतर कई स्थानों से कॉल करने की आवश्यकता है, मैं प्रोटोकॉल एन्कापुलेशन के कारण एसओएपी सेवा के रूप में कार्यान्वित करता हूं, साथ ही HTTP ओवरहेड के बिना अंतर्निहित ऑब्जेक्ट का उपयोग करने की क्षमता जहां यह समझ में आता है।

4

ठीक है इस विषय पर स्टैक ओवरफ़्लो में ज्ञान का भरपूर धन है।

मुझे लगता है कि आरईएसटी की भावना को व्यक्त करने वाला सबसे अच्छा लेख और एसओएपी जैसी प्रौद्योगिकियों के मुकाबले यह कैसे तुलना करता है How I explained REST to my wife है।

एसओएपी के विपरीत, आरईएसटी मानक नहीं है, यह संसाधनों के आसपास केंद्रित संसाधनों और चीजों के आसपास केंद्रित है। HTTP क्रियाएं प्राप्त करें, पोस्ट करें, पुट करें और हटाएं सामान्य कार्य हैं जिन्हें आप किसी संसाधन के विरुद्ध लागू कर सकते हैं। एसओएपी एक मानक है जो इन क्रियाओं को अनदेखा करता है और एक अधिक व्यापक प्रोटोकॉल का आविष्कार किया है जो अधिकतम इंटरऑपरेबिलिटी के लिए सबसे लोकप्रिय क्रिया HTTP पोस्ट के शीर्ष पर काम करता है। अधिकांश समय यह जटिलता अनावश्यक है और एक संसाधन के लिए एक सरल HTTP GET अनुरोध सामान्य रूप से पर्याप्त परिणाम प्राप्त करने के लिए SOAP + XML के 1KB + के संभावित रूप से पर्याप्त हो सकता है।

आप इसका अर्थ क्या है इसके बारे में अधिक जानकारी के लिए Roy Fielding's blog (आरईएसटी का आविष्कारक) भी देख सकते हैं।

+0

पत्नी स्पष्टीकरण पर Greeeeeat लिंक, निश्चित रूप से एक निश्चित रूप से बुकमार्क! – jaywon

+0

पत्नी स्पष्टीकरण के लिए वाह! कैंट का मानना ​​है कि सिर्फ ऊपर की तरह है। एक लाख के लायक! – Achow

+2

अफसोस की बात यह है कि अब यह उपलब्ध नहीं है, लेखक ने इसे हटा दिया। – Tanoh

1

1) आरईएसटी एसओएपी 2 से अधिक सरल और उपयोग करने में आसान है) एसईएपी एक्सएमएल का उपयोग करते समय आरईएसटी वेब सेवाओं के उत्पादन या उपभोग के लिए HTTP प्रोटोकॉल का उपयोग करता है। 3) आरओएसटी एसओएपी की तुलना में हल्के वजन और मोबाइल उपकरणों और पीडीए में पसंदीदा विकल्प है। 4) आरईएसटी टेक्स्ट, जेएसओएन और एक्सएमएल जैसे विभिन्न प्रारूपों का समर्थन करता है जबकि एसओएपी केवल एक्सएमएल का समर्थन करता है। 5) प्रदर्शन में सुधार के लिए आरईएसटी वेब सेवा कॉल को कैश किया जा सकता है।

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