वेब सेवाओं के लिए SOAP या REST? [बन्द है]

Question

क्या वेब सेवा करने के लिए REST एक बेहतर तरीका है या SOAP है? या वे विभिन्न समस्याओं के लिए अलग-अलग उपकरण हैं? या यह एक अति सूक्ष्म मुद्दा है - अर्थात, एक निश्चित अखाड़े में दूसरे की तुलना में थोड़ा बेहतर है, आदि?

मैं विशेष रूप से उन अवधारणाओं और PHP-ब्रह्मांड के संबंध और आधुनिक उच्च-अंत वेब-अनुप्रयोगों के बारे में जानकारी की सराहना करूंगा।

Comments

आज की दुनिया में करने पर विचार JSON आधारित बाकी प्रक्रिया

— ErstwhileIII

संबंधित लेकिन डुप्लिकेट नहीं किया गया धागा: stackoverflow.com/questions/34624813/…

— smwikipedia

की डुप्लिकेट - stackoverflow.com/questions/19884295/soap-vs-rest-differences

— राउल

संभव डुप्लिकेट - stackoverflow.com/questions/19884295/soap-vs-rest-differences

— सेलाकैन

Answer 1

जब मैंने Hewlett-Packard में काम कर रहा था, तो मूल कल्पना से, कोड पीढ़ी और WSDL पीढ़ी सहित, पहले SOAP सर्वरों में से एक का निर्माण किया। मैं कुछ के लिए साबुन का उपयोग करने की अनुशंसा नहीं करता।

संक्षिप्त नाम "SOAP" एक झूठ है। यह सरल नहीं है, यह ऑब्जेक्ट-ओरिएंटेड नहीं है, यह एक्सेस नियमों को परिभाषित नहीं करता है। यह, यकीनन, एक प्रोटोकॉल है। यह डॉन बॉक्स का अब तक का सबसे खराब नमूना है, और यह काफी सामर्थ्य है, क्योंकि वह "COM" पर चलने वाला व्यक्ति है।

SOAP में कुछ भी उपयोगी नहीं है जिसे परिवहन के लिए REST के साथ नहीं किया जा सकता है, और JSON, XML, या डेटा प्रतिनिधित्व के लिए सादा पाठ भी। परिवहन सुरक्षा के लिए, आप https का उपयोग कर सकते हैं। प्रमाणीकरण के लिए, मूल स्थिति। सत्र के लिए, कुकीज़ है। REST संस्करण सरल, स्पष्ट, तेज़ी से चलेगा और कम बैंडविड्थ का उपयोग करेगा।

एक्सएमएल-आरपीसी स्पष्ट रूप से अनुरोध, प्रतिक्रिया और त्रुटि प्रोटोकॉल को परिभाषित करता है, और अधिकांश भाषाओं के लिए अच्छे पुस्तकालय हैं। हालाँकि, XML कई कार्यों के लिए आपकी आवश्यकता से अधिक भारी है।

Comments

आपने यह उल्लेख करने के लिए उपेक्षा की कि REST वेब सेवा के लिए सेवा-आवरण लिखने से SOAP वेब सेवा WSDL से तुरंत उत्पन्न होने वाली कक्षाओं की तुलना में 100000x अधिक समय लगेगा। IMO REST डेटा की एक बूँद पाने के लिए अच्छा है, जिसे आपको काम नहीं करना है। लेकिन अगर आप एक वस्तु प्राप्त करना चाहते हैं, तो SOAP जल्दी और आसानी से लागू होता है। अधिक जानकारी के लिए मेरी पोस्ट यहाँ देखें: stackoverflow.com/questions/3285704/…

— जोश एम।

यदि आप एक आवरण उत्पन्न करना चाहते हैं, तो इसके बजाय JSON डिकोडर का उपयोग करने पर विचार करें। शांति से सोप को आराम करने दें।

— १vo पर इवो दनिहेलका

इस उत्तर को इतने उथल-पुथल और उद्वेलित होते देखना निराशाजनक है। यह एक उपयोगी उत्तर नहीं है। "SOAP में कुछ भी उपयोगी नहीं है जो REST के साथ नहीं किया जा सकता है .."। तो इस आदमी ने हर संभव समस्या की जांच की है जिसे किसी को हल करना पड़ सकता है और यह सुरक्षित रूप से कह सकता है कि आपकी वेब सेवा को SOAP (WS- * यहाँ निहित नहीं लगता है) का उपयोग नहीं करना चाहिए? हाँ सही। मैं REST> WS- * या SOAP की मजबूत रो सुन कर थक गया हूँ .. यह मुश्किल से तुलनीय है।

— फीका

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

— जॉन सॉन्डर्स

मैंने पहली SOAP वेब सेवाओं में से एक (2002 में; Google खोज एपीआई) का निर्माण किया। सिर्फ इस बात की पुष्टि करते हुए कि मृदुघे क्या कहते हैं, SOAP एक अच्छी तकनीक नहीं थी। सौभाग्य से यह अब तनावपूर्ण है और कोई भी इसे अजीब तरह के उद्यम संदर्भों के बाहर उपयोग करने पर गंभीरता से विचार नहीं करता है।

— नेल्सन

Answer 2

REST एक आर्किटेक्चर है, SOAP एक प्रोटोकॉल है।

वह पहली समस्या है।

आप किसी REST एप्लिकेशन में SOAP लिफाफे भेज सकते हैं।

SOAP अपने आप में वास्तव में बहुत बुनियादी और सरल है, यह WSS- * के शीर्ष पर मानक है जो इसे बहुत जटिल बनाते हैं।

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

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

HTTP पर भेजे गए JSON पैकेट जरूरी नहीं कि एक REST आर्किटेक्चर है, यह केवल URL के लिए संदेश है। सभी पूरी तरह से व्यावहारिक हैं, लेकिन REST मुहावरे के प्रमुख घटक हैं। हालांकि दोनों को भ्रमित करना आसान है। लेकिन सिर्फ इसलिए कि आप HTTP अनुरोधों की बात कर रहे हैं जरूरी नहीं कि आपके पास एक REST आर्किटेक्चर हो। आपके पास कोई ऐसा HTTP एप्लिकेशन हो सकता है जिसमें कोई HTTP न हो (मन में, यह दुर्लभ है)।

इसलिए, यदि आपके पास सर्वर और उपभोक्ता हैं जो SOAP, SOAP और WSS स्टैक के साथ "आरामदायक" हैं तो आपकी अच्छी सेवा कर सकते हैं। यदि आप अधिक तदर्थ चीजें कर रहे हैं और वेब ब्राउज़र के साथ बेहतर इंटरफ़ेस चाहते हैं, तो HTTP पर कुछ लाइटर प्रोटोकॉल भी अच्छी तरह से काम कर सकते हैं।

Comments

इस मामले में, मुझे लगता है कि हम एक प्रोटोकॉल पर दो आर्किटेक्चर के बारे में बात कर रहे हैं। REST वास्तव में एक आर्किटेक्चर है जबकि SOAP मौजूदा प्रोटोकॉल पर एक नए प्रोटोकॉल को परिभाषित करने की कोशिश करता है, जिसके शीर्ष पर आपको RPC आर्किटेक्चर लागू करना चाहिए। बेवकूफ-OAP।

यह स्पष्ट रूप से इस पृष्ठ पर दिखाई देने वाले शेख़ी की तुलना में बहुत बेहतर जवाब है

— मिकी डी

Answer 3

REST SOAP से एक मौलिक भिन्न प्रतिमान है। REST पर एक अच्छा पढ़ा जा सकता है: मैंने अपनी पत्नी को REST कैसे समझाया ।

यदि आपके पास इसे पढ़ने का समय नहीं है, तो यहां संक्षिप्त संस्करण है: REST "संज्ञा" पर ध्यान केंद्रित करके एक प्रतिमान बदलाव का एक सा है, और "क्रियाओं" की संख्या को रोकना आप उन संज्ञाओं पर लागू कर सकते हैं। केवल अनुमत क्रिया "गेट", "पुट", "पोस्ट" और "डिलीट" हैं। यह SOAP से भिन्न होता है जहां कई अलग-अलग क्रियाओं को कई अलग-अलग संज्ञाओं (यानी कई अलग-अलग कार्यों) पर लागू किया जा सकता है।

REST के लिए, चार क्रियाएं संबंधित HTTP अनुरोधों के लिए मैप करती हैं, जबकि URL द्वारा संज्ञाओं की पहचान की जाती है। यह एसओएपी की तुलना में राज्य प्रबंधन को अधिक पारदर्शी बनाता है, जहां अक्सर यह स्पष्ट नहीं होता है कि सर्वर पर क्या स्थिति है और क्लाइंट पर क्या है।

व्यवहार में, हालांकि यह सबसे दूर हो जाता है, और REST आमतौर पर साधारण HTTP अनुरोधों को संदर्भित करता है जो JSON में परिणाम देता है , जबकि SOAP एक अधिक जटिल एपीआई है जो XML के आसपास से गुजरता है। दोनों के अपने फायदे और नुकसान हैं, लेकिन मैंने पाया है कि मेरे अनुभव में REST आमतौर पर बेहतर विकल्प है क्योंकि आपको शायद ही कभी SOAP से मिलने वाली पूर्ण कार्यक्षमता की आवश्यकता हो।

Comments

केवल अनुमत क्रिया "गेट", "पुट" और "डिलीट" हैं? पोस्ट और विकल्प के बारे में क्या?

— एंड्रयू स्वान

क्षमा करें, मैं POST का उल्लेख करना भूल गया। विकल्प (और हेड) को आरईएस विनिर्देश का हिस्सा नहीं माना जाता है।

— १०:४५ पर टोलुजु २०'०

@toluju मुझे पता नहीं था कि REST के पास एक विनिर्देश था। यह एक वास्तुशिल्प शैली है और हालांकि यह सच हो सकता है कि विकल्प शायद ही कभी उपयोग किए जाते हैं मुझे नहीं लगता कि आप HEAD के बारे में भी ऐसा कह सकते हैं।

— खाली

HEAD, OPTIONS और TRACE वे सभी तरीके हैं जो URL पर ही सामग्री के बारे में सर्वर मेटा-जानकारी के बारे में पूछताछ करते हैं। जैसे कि वे REST- शैली अनुप्रयोगों के लिए सीमांत उपयोग के हैं। मैं एक विनिर्देश के रूप में सही खड़ा हूँ। REST का मुख्य विनिर्देश HTTP युक्ति ही है।

— तोलुजू

एक नोट के रूप में, "बाकी आमतौर पर ... संदर्भित करता है ... जो JSON में परिणाम का अनुरोध करता है" - सही नहीं है। लौटाया गया मीडिया-प्रकार किसी भी प्रारूप में प्रतिबंधित या डिफ़ॉल्ट नहीं है। वास्तव में, कई REST सेवाएँ एप्लिकेशन / xml, वीडियो या अन्य मीडिया-प्रकार लौटाती हैं। मेरे अनुभव में, उदाहरण के लिए, निगमों में, REST आधारित वेब-सेवाएं XML को JSON के पक्ष में लौटाती हैं। किसी भी स्थिति में, यह उस सेवा पर निर्भर करता है जो वापस आ जाती है और क्लाइंट इस सामग्री-प्रकार की बातचीत में HTTP "स्वीकार" हैडर के माध्यम से भाग ले सकता है।

— डेरेल टीग

Answer 4

2012 प्रश्न के लिए त्वरित न्यूनता:

REST के लिए वास्तव में अच्छी तरह से काम करने वाले क्षेत्र निम्नलिखित हैं:

• सीमित बैंडविड्थ और संसाधन। याद रखें कि रिटर्न संरचना वास्तव में किसी भी प्रारूप (डेवलपर परिभाषित) में है। साथ ही, किसी भी ब्राउज़र का उपयोग किया जा सकता है क्योंकि REST दृष्टिकोण मानक GET, PUT, POST और DELETE क्रियाओं का उपयोग करता है। फिर से, याद रखें कि REST XMLHttpRequest ऑब्जेक्ट का उपयोग कर सकता है जो आज के अधिकांश आधुनिक ब्राउज़र का समर्थन करता है, जो AJAX के अतिरिक्त बोनस को जोड़ता है।

• पूरी तरह से स्टेटलेस ऑपरेशन।  यदि किसी ऑपरेशन को जारी रखने की आवश्यकता है, तो REST सबसे अच्छा तरीका नहीं है और SOAP इसे बेहतर तरीके से फिट कर सकता है। हालाँकि, यदि आपको स्टेटलेस CRUD (क्रिएट, रीड, अपडेट और डिलीट) ऑपरेशंस की आवश्यकता है, तो REST यह है।

• कैशिंग स्थितियों।  यदि REST दृष्टिकोण के पूरी तरह से स्टेटलेस ऑपरेशन के कारण जानकारी को कैश किया जा सकता है, तो यह सही है। उपरोक्त तीनों में बहुत सारे समाधान हैं।

तो मैं भी SOAP पर विचार क्यों करूंगा? फिर से, सोप काफी परिपक्व और अच्छी तरह से परिभाषित है और एक पूर्ण विनिर्देश के साथ आता है। REST दृष्टिकोण बस यही है, एक दृष्टिकोण और विकास के लिए व्यापक खुला है, इसलिए यदि आपके पास निम्नलिखित है तो SOAP एक महान समाधान है:

• अतुल्यकालिक प्रसंस्करण और आह्वान।  यदि आपके आवेदन को विश्वसनीयता और सुरक्षा की गारंटी स्तर की आवश्यकता है, तो SOAP 1.2 इस प्रकार के संचालन को सुनिश्चित करने के लिए अतिरिक्त मानक प्रदान करता है। WSRM जैसी चीजें - WS- विश्वसनीय मैसेजिंग।

• औपचारिक अनुबंध।  यदि दोनों पक्षों (प्रदाता और उपभोक्ता) को विनिमय प्रारूप पर सहमत होना है तो SOAP 1.2 इस प्रकार की बातचीत के लिए कठोर विनिर्देश देता है।

• राज्य संचालन। यदि एप्लिकेशन को प्रासंगिक जानकारी और संवादी स्थिति प्रबंधन की आवश्यकता है, तो SOAP 1.2 में उन चीजों (सुरक्षा, लेनदेन, समन्वय, आदि) का समर्थन करने के लिए WS * संरचना में अतिरिक्त विनिर्देशन है। तुलनात्मक रूप से, REST दृष्टिकोण डेवलपर्स को इस कस्टम पाइपलाइन का निर्माण करेगा।

http://www.infoq.com/articles/rest-soap-when-to-use-each

Answer 5

SOAP में वर्तमान में बेहतर उपकरणों का लाभ है जहां वे सर्विस लेयर दोनों के लिए बहुत सारे बॉयलरप्लेट कोड के साथ-साथ किसी भी दिए गए WSDL से क्लाइंट जेनरेट करेंगे।

REST सरल है, परिणाम के रूप में बनाए रखना आसान हो सकता है, वेब आर्किटेक्चर के दिल में स्थित है, बेहतर प्रोटोकॉल दृश्यता के लिए अनुमति देता है, और डब्ल्यूडब्ल्यूडब्ल्यू के आकार में ही पैमाने पर साबित हुआ है। कुछ रूपरेखाएँ आपको REST सेवाओं का निर्माण करने में मदद करती हैं, जैसे रूबी ऑन रेल्स, और कुछ भी आपको क्लाइंट लिखने में मदद करती हैं, जैसे ADO.NET डेटा सेवाएँ। लेकिन अधिकांश भाग के लिए, उपकरण समर्थन की कमी है।

Comments

REST को बनाए रखना आसान है - आपको केवल REST विधियों की संरचना या उनके द्वारा लौटाए गए डेटा की संरचना में किसी भी मिनट परिवर्तन के लिए API प्रलेखन की निगरानी करनी होगी। यदि आपको कोई परिवर्तन दिखाई देता है तो आपको अपने हाथ से लिखे गए कोड को मैन्युअल रूप से बदलना होगा जो विधि की प्रतिक्रिया को पार्स करता है। SOAP के साथ आपके संदर्भ पर राइट-क्लिक करने और "अपडेट" का चयन करने और फिर कुछ संकलन त्रुटियों को ठीक करने का भार है। (व्यंग्य में नि: शुल्क शामिल है।)

— जोश एम।

@ जोशम: यदि आपने एक नरम और लचीले विनिर्देश के आधार पर उत्पन्न प्रतिक्रिया की प्रतिक्रिया को पार्स करने के लिए हाथ से लिखा कोड है, तो आप कीट का उपयोग नहीं कर रहे हैं; आपने एक संसाधन पेड़ को हार्डकोड किया है। यह c: \ windows \ temp या जो कुछ भी कोडिंग के समान है, उपयोग करने के लिए PROPER स्थान के लिए क्वेरी करने का विरोध करता है। क्योंकि यह थोड़ी देर के लिए काम करता है, यह करने के लिए सही काम नहीं करता है, और न ही यह अच्छा कोडिंग अभ्यास है।

— पॉल सोनियर

@PaulSonier: अक्सर नरम और लचीले विनिर्देशन से प्रतिक्रिया को पार्स करने का सही तरीका क्या है? मुझे लगता है कि हार्डकोड ब्रूट कोड बहुत अच्छा नहीं है, लेकिन मैं रेस्टफुल एपीआई के क्लाइंट एंड पर सलाह और उदाहरण ढूंढ रहा हूं और अब तक कम कर रहा हूं। मुझे लगता है कि यह जोश पर हो रहा है - SOAP को बॉयलरप्लेट कोड के टन की आवश्यकता होती है, लेकिन इसके लिए आपको जो मिलता है वह दस्तावेज़ प्रारूप और प्रकार की सुरक्षा पर एक दृश्यमान और लागू करने योग्य अनुबंध है; रेस्टफुल एपीआई कॉन्ट्रैक्ट और बायलरप्लेट को छोड़ देते हैं और अक्सर सरल दिखते हैं, जो इससे कोई फर्क नहीं पड़ता, लेकिन ... आप संसाधन पेड़ को हार्डकोड कैसे नहीं करते हैं ?

— 1

(मुझे HATEOAS तर्क मिलता है, लेकिन एक उदाहरण के रूप में , martinfowler.com/articles/richardsonMaturityModel.html का उपयोग करते हुए, कहते हैं - XML ​​को पार्स करने के बाद, अभी भी आवश्यक तत्व व्याख्या की एक उचित मात्रा है, इससे पहले कि आप लिंक तत्वों को प्राप्त करें "हाइपरमीडिया नियंत्रण"।)

— मेटामैट

यदि आप SOAP (सभी WS- * सामान) की उन्नत सुविधाओं में खुदाई करते हैं, तो आपको जल्दी से पता चलेगा कि उपकरण इनका इतनी अच्छी तरह से (ईएआई और ईएसबी उत्पादों सहित) समर्थन नहीं करते हैं और फ्रेमवर्क अलग-अलग तरीके से व्यवहार कर सकते हैं (जैसे मेट्रो बनाम सी # ) "" और जैसे सूक्ष्मता के लिए null। और उत्पन्न बॉयलरप्लेट कोड आमतौर पर केवल SOAP द्वारा बोझ के कारण काम करने के लिए होता है।

— आरडीएस

Answer 6

एसओएपी टूलिंग दृष्टिकोण से उपयोगी है क्योंकि डब्ल्यूएसडीएल इतनी आसानी से टूल द्वारा खपत होती है। तो, आप अपनी पसंदीदा भाषा में आपके लिए उत्पन्न वेब सेवा ग्राहकों को प्राप्त कर सकते हैं।

REST AJAX'y वेब पृष्ठों के साथ अच्छा खेलता है। यदि आप अपने अनुरोधों को सरल रखते हैं, तो आप सीधे अपने जावास्क्रिप्ट से सेवा कॉल कर सकते हैं, और यह बहुत काम आता है। आपकी प्रतिक्रिया XML में किसी भी नामस्थान से दूर रहने की कोशिश करें, मैंने उन ब्राउज़रों को देखा है। तो, xsi: प्रकार शायद आपके लिए काम करने वाला नहीं है, कोई अत्यधिक जटिल XML स्कीमा नहीं है।

REST का प्रदर्शन बेहतर है। REST प्रतिसाद उत्पन्न करने वाले कोड की CPU आवश्यकताएँ SOAP चौखटे की तुलना में कम होती हैं। और, यदि आपके पास अपनी XML पीढ़ी के बत्तख सर्वर साइड पर पंक्तिबद्ध हैं, तो आप प्रभावी रूप से क्लाइंट के लिए XML को स्ट्रीम कर सकते हैं। तो, कल्पना कीजिए कि आप डेटाबेस कर्सर की पंक्तियों को पढ़ रहे हैं। जब आप एक पंक्ति पढ़ते हैं, तो आप इसे XML तत्व के रूप में प्रारूपित करते हैं, और आप इसे सीधे सेवा उपभोक्ता को लिखते हैं। इस तरह, आपको अपने XML आउटपुट को लिखना शुरू करने से पहले सभी डेटाबेस पंक्तियों को मेमोरी में इकट्ठा करने की आवश्यकता नहीं है - आप एक ही समय में पढ़ते हैं और लिखते हैं। REST के लिए काम करने के लिए स्ट्रीमिंग पाने के लिए उपन्यास टेम्प्लेटिंग इंजन या XSLT देखें।

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

मेरी निर्णय लेने की प्रक्रिया इस प्रकार है: यदि मैं चाहता हूं कि मेरी सेवा उपभोक्ताओं द्वारा आसानी से टाल दी जाए, और मेरे द्वारा लिखे गए संदेश मध्यम-से-छोटे-ईश (10 एमबी या उससे कम) होंगे, और मुझे कुछ अतिरिक्त सीपीयू जलाने का मन नहीं है। सर्वर पर चक्र, मैं SOAP के साथ जाता हूं। यदि मुझे वेब ब्राउज़र पर AJAX की सेवा करने की आवश्यकता है, या मुझे स्ट्रीम करने के लिए चीज़ की आवश्यकता है, या मेरी प्रतिक्रियाएँ विशाल हैं, तो मैं REST जाता हूं।

अंत में, एसओएपी के आसपास बहुत सारे महान मानक बनाए गए हैं, जैसे डब्ल्यूएस-सिक्योरिटी और स्टेटफुल वेब सर्विसेज प्राप्त करना, जिसे आप सही टूल का उपयोग करने पर प्लग इन कर सकते हैं। इस तरह के सामान से वास्तव में फर्क पड़ता है, और आपको बालों की कुछ आवश्यकताओं को पूरा करने में मदद मिल सकती है।

Answer 7

मुझे पता है कि यह एक पुराना प्रश्न है लेकिन मुझे अपना उत्तर पोस्ट करना होगा - शायद कोई इसे उपयोगी समझेगा। मुझे विश्वास नहीं हो रहा है कि कितने लोग SOAP पर REST की सिफारिश कर रहे हैं। मैं केवल यह मान सकता हूं कि ये लोग डेवलपर नहीं हैं या वास्तव में किसी भी उचित आकार की REST सेवा को कभी लागू नहीं किया है। REST सेवा को लागू करने से SOAP सेवा को लागू करने में अधिक समय लगता है। और अंत में यह बहुत गड़बड़ हो जाता है। यहाँ मैं समय का 99% SOAP चुनूँगा कारण हैं:

1) एक REST सेवा को लागू करने से SOAP सेवा को लागू करने में अधिक समय लगता है। WSDL और आउटपुट प्रॉक्सी क्लासेस और क्लाइंट्स में पढ़ने के लिए सभी आधुनिक भाषाओं / चौखटों / प्लेटफार्मों के लिए उपकरण मौजूद हैं। REST सेवा को कार्यान्वित करना हाथ से किया जाता है और - इसे प्राप्त करें - प्रलेखन को पढ़कर। इसके अलावा, इन दो सेवाओं को लागू करते समय, आपको "अनुमान" बनाना होगा कि पाइप में क्या वापस आएगा क्योंकि कोई वास्तविक स्कीमा या संदर्भ दस्तावेज़ नहीं है।

2) क्यों एक सेवा है कि XML वैसे भी देता है लिखें? एकमात्र अंतर यह है कि REST के साथ आपको पता नहीं है कि प्रत्येक तत्व / विशेषता किस प्रकार का प्रतिनिधित्व करती है - आप इसे लागू करने के लिए अपने दम पर हैं और आशा करते हैं कि एक दिन एक स्ट्रिंग उस क्षेत्र में नहीं आती है जिसे आपने सोचा था कि वह हमेशा एक इंट था। एसओएपी डब्ल्यूएसडीएल का उपयोग करके डेटा संरचना को परिभाषित करता है इसलिए यह एक नो-ब्रेनर है।

3) मैंने शिकायत सुनी है कि SOAP के साथ आपके पास SOAP लिफाफे का "ओवरहेड" है। इस दिन और उम्र में, क्या हमें वास्तव में मुट्ठी भर बाइट्स के बारे में चिंता करने की ज़रूरत है?

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

5) हमें प्रत्येक संसाधन के लिए "पठनीय" URL की आवश्यकता क्यों है? यदि हम सेवा को लागू करने के लिए एक उपकरण का उपयोग कर रहे थे, तो क्या हम वास्तव में वास्तविक URL की परवाह करते हैं?

जरूरत है मैं चलूँ?

Comments

यह एक अच्छा जवाब है लेकिन ईमानदारी से, आप यह नहीं समझते हैं कि REST क्या है। इसे जानने के लिए आप इस प्रश्न के 2 सर्वश्रेष्ठ उत्तर पढ़ सकते हैं। आप उनकी तुलना एक समान आर्किटेक्चर के रूप में कर रहे हैं, जबकि REST केवल एक प्रतिमान है। यह "पिज्जा" के साथ "रेस्तरां शिष्टाचार" की तुलना करने के समान है। क्या कांटा और चाकू के साथ खाना या पिज्जा खाना बेहतर है? "मैं पिज्जा के साथ जाऊंगा" - आप कहते हैं। और जैसा कि पहले उत्तर से पता चलता है, आप आसानी से दोनों का उपयोग कर सकते हैं - एक कांटा और एक चाकू के साथ पिज्जा खाएं।

— बेगमक्स

"इस दिन और उम्र में, क्या हमें वास्तव में मुट्ठी भर बाइट्स के बारे में चिंता करने की ज़रूरत है?" उम्म, हाँ हम करते हैं! जहां से मैं हूं, मैं कई ऑनलाइन कंप्यूटर गेम खेल सकता हूं, लेकिन ब्लिज़ार्ड ऑफ़ वर्ल्ड ऑफ डेवलेपर्स डेवलपर्स ने आपके विचार को सब्सक्राइब किया और नेटवर्क ट्रैफ़िक को अनुकूलित करने के लिए कभी परेशान नहीं किया, इसलिए इसका एकमात्र गेम मुझे लगातार डिस्कनेक्ट से मिलता है। इस तरह के एक पुराने खेल के लिए, वाह बहुत नेटवर्क ट्रैफिक है। यह किसी भी दिन और उम्र में अच्छा नहीं है, क्योंकि हमेशा सीमांत कनेक्शन वाले लोग होंगे जहां कुछ विकास के समय को बचाने के लिए एक बेकार दृष्टिकोण बस इसे तोड़ देगा।

— 10

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

— कीथजग्रेंट

ऊपर अपने जवाब @JoshM तो "से अपने प्रश्न के रूप में ही है stackoverflow.com/questions/3285704/... "?

— मुकुस

@ मूकस - आरोप के रूप में दोषी ...?

— जोश एम।

Answer 8

मेरे द्वारा लिखे गए अधिकांश एप्लिकेशन सर्वर-साइड C # या Java, या WinForms या WPF में डेस्कटॉप अनुप्रयोग हैं। इन एप्लिकेशनों को REST द्वारा प्रदान की जाने वाली धन से अधिक समृद्ध सेवा API की आवश्यकता होती है। इसके अलावा, मैं अपने वेब सेवा ग्राहक को बनाने में एक दो मिनट से अधिक खर्च नहीं करना चाहता। डब्लूएसडीएल प्रोसेसिंग क्लाइंट जेनरेशन टूल मुझे अपने क्लाइंट को लागू करने और व्यावसायिक मूल्य जोड़ने के लिए आगे बढ़ने की अनुमति देता है।

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

उस ने कहा, जावास्क्रिप्ट के लिए कुछ SOAP क्लाइंट हैं; मुझे पता है कि jQuery के पास एक है। इस प्रकार, SOAP को जावास्क्रिप्ट से लिया जा सकता है; JSON स्ट्रिंग्स को लौटाने वाली REST सेवा जितनी अच्छी तरह से नहीं है। इसलिए यदि मेरे पास एक वेब सेवा है जिसे मैं पर्याप्त जटिल बनाना चाहता था, तो यह ग्राहक तकनीकों और उपयोगों की एक मनमानी संख्या के लिए लचीला था, मैं SOAP के साथ जाऊंगा।

Answer 9

मैं आपको पहले REST के साथ जाने की सलाह दूंगा - यदि आप JAX-RS और जर्सी कार्यान्वयन पर जावा लुक का उपयोग कर रहे हैं । REST बहुत सरल और कई भाषाओं में अंतर करने में आसान है।

जैसा कि अन्य लोगों ने इस सूत्र में कहा है, एसओएपी के साथ समस्या इसकी जटिलता है जब अन्य WS- * विनिर्देशों में आते हैं और अगर आप WSDL, XSDs, SOAP, WS- एड्रेसिंग आदि के गलत हिस्सों में भटकते हैं तो अनगिनत अंतर मुद्दे हैं।

REST v SOAP डिबेट को जज करने का सबसे अच्छा तरीका इंटरनेट पर दिखता है - वेब स्पेस, google, amazon, ebay, twitter et al - में सभी बड़े खिलाड़ियों का बहुत उपयोग और SOAP वाले पर RESTful APIs को पसंद करते हैं।

REST के साथ जाने का दूसरा अच्छा तरीका यह है कि आप एक वेब एप्लिकेशन और RI फ्रंट एंड के बीच बहुत सारे कोड और इन्फ्रास्ट्रक्चर का पुन: उपयोग कर सकते हैं। उदाहरण के लिए आपके संसाधनों के HTML बनाम XML बनाम JSON का प्रतिपादन करना आम तौर पर JAX-RS और अंतर्निहित विचारों जैसे चौखटे के साथ बहुत आसान है - इसके अलावा एक वेब ब्राउज़र का उपयोग करके Restful संसाधनों के साथ काम करना आसान है

Comments

+1 पुनः "न्याय करने का सबसे अच्छा तरीका ..." एक अच्छा उदाहरण Google का जावास्क्रिप्ट एपीआई है। मूल रूप से SOAP में, फिर डेवलपर की शिकायतों के जवाब में, REST में वापस ले लिया गया। Google # 1 API बनने के कुछ समय बाद (अनुरोधों के द्वारा) - यह जानकर आश्चर्य हुआ कि यह मानचित्र API की धड़कन करता है लेकिन जाहिर तौर पर उसने ऐसा किया है (JS API पर लीड डेवलपर के अनुसार)।

— डौग

Answer 10

मुझे यकीन है कि डॉन बॉक्स ने सोप को एक मजाक के रूप में बनाया - 'देखो तुम वेब पर आरपीसी विधियों को कॉल कर सकते हो ' और आज कराहते हैं जब उसे पता चलता है कि वेब मानकों का एक फूला हुआ दुःस्वप्न बन गया है :-)

REST अच्छा, सरल, हर जगह लागू किया गया (इसलिए मानकों से अधिक 'मानक') तेज और आसान है। REST का उपयोग करें।

Comments

"मुझे यकीन है कि डॉन बॉक्स ने सोप को एक मजाक के रूप में बनाया था - 'देखो आप वेब पर आरपीसी विधियों को कॉल कर सकते हैं" "शायद सच है। +1

— मुकुस

Answer 11

मुझे लगता है कि दोनों की अपनी जगह है। मेरी राय में:

SOAP : नींव परत पर विरासत / महत्वपूर्ण प्रणालियों और एक वेब / वेब-सेवा प्रणाली के बीच एकीकरण के लिए एक बेहतर विकल्प, जहां WS- * समझदारी (सुरक्षा, नीति, आदि) बनाते हैं।

RESTful : वेबसाइटों के बीच एकीकरण के लिए एक बेहतर विकल्प, सार्वजनिक एपीआई के साथ, परत के शीर्ष पर (देखें, यानी, यूआरआई को कॉल करने वाले जावास्क्रिप्ट)।

Answer 12

एक बात जिसका उल्लेख नहीं किया गया है वह यह है कि एक SOAP लिफाफे में हेडर के साथ-साथ शरीर के अंग भी हो सकते हैं। यह आपको XML जानकारी को बैंड की जानकारी भेजने और प्राप्त करने के लिए पूर्ण अभिव्यक्ति का उपयोग करने देता है। REST, जहाँ तक मुझे पता है, आपको HTTP हेडर और परिणाम कोड तक सीमित करता है।

(ओटोह, क्या आप "हेडर" को बैंड डेटा से बाहर भेजने के लिए REST सेवा के साथ कुकीज़ का उपयोग कर सकते हैं?)

Comments

शायद इसलिए कि आप गलत हैं? REST आपके द्वारा आवश्यक किसी भी पूर्वनिर्धारित या कस्टम HTTP शीर्ष लेख, और अनुरोध निकाय का उपयोग कर सकता है।

— क्रिस ब्रॉस्की

शायद नहीं। देखो कि तुम क्या एक SOAP हैडर में डाल सकते हैं बनाम क्या आप एक HTTP हेडर में डाल सकते हैं। कब तक एक पंक्ति हो सकती है?

— जॉन सॉन्डर्स

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

— क्रिस ब्रॉस्की

@protonfish: मैं यह संकेत नहीं दे रहा था कि आप HTTP हेडर में महत्वपूर्ण जानकारी नहीं डाल सकते। मैं सोच रहा था कि क्या आप HTTP हेडर में उतनी ही जानकारी डाल सकते हैं जितनी कि एसओएपी हेडर में रखी जा सकती है। जब मैंने पूछा कि एक पंक्ति कितनी लंबी हो सकती है, तो इसका कारण यह है कि मैं इसका उत्तर जानना चाहता था।

— जॉन सॉन्डर्स

@protonfish: मैंने यह भी सोचा था कि एक तरफ "XML की पूर्ण अभिव्यक्ति" और दूसरी तरफ "HTTP हेडर और परिणाम कोड" के बीच अंतर स्पष्ट था। शायद यह उतना स्पष्ट नहीं है जितना मैंने सोचा था।

— जॉन सॉन्डर्स

Answer 13

XML-RPC को अनदेखा न करें। यदि आप एक हल्के समाधान के बाद बस रहे हैं, तो एक प्रोटोकॉल के लिए कहा जाने वाला एक बड़ा सौदा है जिसे पाठ के कुछ पृष्ठों में परिभाषित किया जा सकता है और कम से कम कोड में लागू किया जा सकता है। एक्सएमएल-आरपीसी लगभग वर्षों से है लेकिन थोड़ी देर के लिए फैशन से बाहर हो गया - लेकिन न्यूनतम अपील इसे देर से पुनरुद्धार के कुछ दे रही है।

Answer 14

2012 के ताज़ा (दूसरे बाउंटी द्वारा) प्रश्न का उत्तर देना, और आज के परिणामों (अन्य उत्तरों) की समीक्षा करना।

---

SOAP, पेशेवरों और विपक्ष

SOAP 1.2, फायदे और कमियों के बारे में जब "REST" के साथ तुलना की जाती है ... ठीक है, 2007 के बाद से आप WSDL के साथ REST वेब सेवाओं का वर्णन कर सकते हैं , और SOAP प्रोटोकॉल का उपयोग कर सकते हैं ... अर्थात, यदि आप थोड़ा कठिन परिश्रम करते हैं, तो W3C के सभी मानक 1.2 वेब सेवा प्रोटोकॉल स्टैक REST हो सकता है !

यह एक अच्छा प्रारंभिक बिंदु है, क्योंकि हम एक ऐसे परिदृश्य की कल्पना कर सकते हैं जिसमें सभी दार्शनिक और पद्धति संबंधी चर्चाओं को अस्थायी रूप से टाला जाता है। हम समान सेवाओं में "NON-SOAP-REST" के साथ तकनीकी रूप से "SOAP-REST" की तुलना कर सकते हैं,

• SOAP-REST (= "REST-SOAP"): जैसा कि L.Mandel द्वारा दिखाया गया है , WSDL2 एक REST webservice का वर्णन कर सकता है, और, अगर हमें लगता है कि एक्सएमएल को SOAP में कवर किया जा सकता है, तो सभी कार्यान्वयन "SOAP-REST" होंगे। ।

• NON-SOAP-REST : कोई भी REST वेब सेवा जो SOAP नहीं हो सकती ... जो कि अच्छी तरह से ज्ञात REST उदाहरणों का "90%" है। कुछ एक्सएमएल का उपयोग नहीं करते हैं (उदाहरण के लिए विशिष्ट AJAX RESTs JSON का उपयोग करते हैं), कुछ SOAP हेडर या नियमों के बिना एक और XML स्ट्रक्यूटर्स का उपयोग करते हैं। पुनश्च: अनौपचारिकता से बचने के लिए, हम तुलना में REST स्तर 2 को मान सकते हैं ।

बेशक, अधिक वैचारिक रूप से तुलना करने के लिए, विभिन्न मॉडलिंग दृष्टिकोणों के रूप में "NON-SOAP-REST" के साथ "NON-REST-SOAP" की तुलना करें। इसलिए, वेब सेवाओं के इस वर्गीकरण को पूरा करना:

• NON-REST-SOAP : कोई भी SOAP वेब सेवा जो REST नहीं हो सकती ... जो कि अच्छी तरह से ज्ञात SOAP उदाहरणों का "90%" है।

• NON-REST-NEITHER-SOAP : हां, "वेब सेवाओं मॉडलिंग" के ब्रह्मांड में अन्य चीजें शामिल हैं (जैसे एक्सएमएल-आरपीसी )।

बाकी के चुनावों में एसओएपी

: तुलनीय चीजों की तुलना सोप-बाकी के साथ गैर-सोप-बाकी ।

पेशेवरों

कुछ शब्दों की व्याख्या करते हुए,

• संविदात्मक स्थिरता : सभी प्रकार के अनुबंधों के लिए ("लिखित समझौते"),

  • स्टैंडर्स के उपयोग से : W3C स्टैक के सभी स्तर परस्पर अनुरूप हैं। दूसरी ओर, REST, W3C या ISO मानक नहीं है, और इसमें सेवा के बाह्य उपकरणों के बारे में कोई विवरण नहीं है। इसलिए, जैसा कि मैंने , @DaveWoldrich (20 वोट), @cynicalman (5), @Exitos (0) ने पहले कहा, एक संदर्भ में जहां STANDARDS के लिए आवश्यक हैं, आपको SOAP की आवश्यकता है।

  • सर्वोत्तम प्रथाओं के उपयोग द्वारा : डब्ल्यू 3 सी स्टैक कार्यान्वयन का " क्रिया पहलू" , प्रासंगिक मानव / कानूनी / न्यायिक समझौतों का अनुवाद करता है।

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

लोकप्रियता के आधार पर छंटनी,

• बेहतर उपकरण (~ 70 वोट): SOAP में वर्तमान में 2007 और 2012 के बाद से बेहतर उपकरणों का लाभ है, क्योंकि यह एक अच्छी तरह से परिभाषित और व्यापक रूप से स्वीकृत मानक है। @MarkCidade (27 वोट), @DaveWoldrich (20), @JoshM (13), @TravisHeseman (9) देखें।

• स्टैंडर्स अनुपालन (25 वोट): जैसा कि I , @DaveWoldrich (20 वोट), @cynicalman (5), @Exitos (0) ने पहले कहा, एक संदर्भ में जहां STANDARDS के लिए आवश्यक हैं, आपको AAP की आवश्यकता है।

• मजबूती : सोप हेडर, @JohnSaunders (8 वोट) का बीमा।

कान्स

• एसओएपी स्ट्रिकुलेट अधिक जटिल (300 से अधिक वोट) है: यहां सभी उत्तर, और "सोप बनाम रेस्ट" के बारे में स्रोत, एसओएपी की अतिरेक और जटिलता के साथ नापसंद के कुछ डिग्री को प्रकट करते हैं। यह औपचारिक सत्यापन (नीचे देखें), और मजबूती (ऊपर देखें) के लिए आवश्यकताओं का एक स्वाभाविक परिणाम है । "REST NON-SOAP" (और XML-RPC, SOAP प्रवर्तक ) अधिक सरल और अनौपचारिक हो सकता है।

• "केवल XML" प्रतिबंध छोटी सेवाओं (~ 50 वोट) का उपयोग करते समय एक प्रदर्शन बाधा है : json.org/xml देखें और यह प्रश्न , या यह अन्य । यह बिंदु @toluju (41), और अन्य लोगों द्वारा दिखाया गया है।
  पुनश्च: चूंकि JSON एक IETF मानक नहीं है , लेकिन हम वेब सॉफ्टवेयर समुदाय के लिए एक वास्तविक मानक पर विचार कर सकते हैं।

---

SOAP के साथ मॉडलिंग सेवाएँ

अब, हम SOAP-NON-REST को NON-SOAP-REST तुलना के साथ जोड़ सकते हैं , और बता सकते हैं कि SOAP का उपयोग करना कब बेहतर है :

• मानकों और स्थिर अनुबंधों की आवश्यकता ("PROS" अनुभाग देखें)। पुनश्च: @saille द्वारा वर्णित एक सामान्य "बी 2 बी मानकों की आवश्यकता है" देखें ।

• उपकरण की आवश्यकता है ("PROS" अनुभाग देखें)। पुनश्च: मानक , और औपचारिक सत्यापन (बेलो देखें) का अस्तित्व , उपकरण स्वचालन के लिए महत्वपूर्ण मुद्दे हैं।

• समानांतर भारी प्रसंस्करण (नीचे "संदर्भ / नींव" अनुभाग देखें): बड़ी और / या धीमी प्रक्रियाओं के साथ, सोप की थोड़ी अधिक जटिलता के साथ कोई फर्क नहीं पड़ता, विश्वसनीयता और स्थायित्व सबसे अच्छा निवेश हैं।

• अधिक सुरक्षा की आवश्यकता : जब HTTPS से अधिक की आवश्यकता होती है, और आपको वास्तव में सुरक्षा के लिए अतिरिक्त सुविधाओं की आवश्यकता होती है, तो SOAP एक बेहतर विकल्प है ( देखें @Bell , 32 वोट)। "अनुरोध / प्रतिक्रिया से अधिक जटिल पथ पर संदेश भेजना या HTTP शामिल नहीं करने वाले परिवहन पर", एस। सेली । XML एक मुख्य मुद्दा है, XML एन्क्रिप्शन , XML हस्ताक्षर और XML Canonicalization के लिए मानक की पेशकश , और, केवल SOAP के साथ आप इन तंत्रों को संदेश में WS- सुरक्षा के रूप में अच्छी तरह से स्वीकार किए गए मानक द्वारा एम्बेड कर सकते हैं ।

• अधिक लचीलापन (कम प्रतिबंध) की आवश्यकता है: SOAP को URI के साथ सटीक पत्राचार की आवश्यकता नहीं है; HTTP पर एनडीडी प्रतिबंधित नहीं है; 4 क्रियाओं को प्रतिबंधित करने की आवश्यकता नहीं है। जैसा कि @TravisHeseman (9 वोट) कहते हैं, यदि आप "ग्राहक प्रौद्योगिकियों और उपयोगों की एक मनमानी संख्या के लिए लचीला" चाहते थे, तो SOAP का उपयोग करें।
  पुनश्च: याद रखें कि XML JSON (et al) की तुलना में अधिक सार्वभौमिक / अभिव्यंजक है।

• औपचारिक सत्यापन की आवश्यकता : यह समझना महत्वपूर्ण है कि डब्ल्यू 3 सी स्टैक औपचारिक तरीकों का उपयोग करता है , और आरईएसटी अधिक अनौपचारिक है। आपका WSDL (एक औपचारिक भाषा ) सेवा विवरण आपकी वेब सेवाओं के इंटरफेस का एक औपचारिक विनिर्देश है, और SOAP एक मजबूत प्रोटोकॉल है जो सभी संभव WSDL नुस्खे को स्वीकार करता है।

संदर्भ

ऐतिहासिक

रुझानों का आकलन करने के लिए आवश्यक ऐतिहासिक परिप्रेक्ष्य है। इस विषय के लिए, 10 या 15 साल के परिप्रेक्ष्य ...

W3C मानकीकरण से पहले, कुछ अराजकता हैं। अलग-अलग चौखटे के साथ इंटरऑपरेबल सेवाओं को लागू करना मुश्किल था, और अधिक कठिन, महंगा और कंपनी के बीच कुछ अंतर को लागू करने में समय लगता है। W3C ढेर मानकों एक प्रकाश, जटिल वेब सेवाओं के सेट में से अंतर्संचालन के लिए एक उत्तर दिया गया है।

AJAX को लागू करने के लिए दिन-प्रतिदिन के कार्यों के लिए, SOAP भारी है ... इसलिए, एक नए सिद्धांत-ढांचे को चुनने के लिए सरल दृष्टिकोण की आवश्यकता है ... और Google, अमेज़ॅन के रूप में बड़े "वेब सॉफ्टवेयर खिलाड़ी", याहू, एट अल, ने सबसे अच्छा विकल्प चुना, जो कि आरईएसटी दृष्टिकोण है। इस संदर्भ में कि REST अवधारणा एक "प्रतिस्पर्धात्मक ढाँचे" के रूप में आई थी, और आज (2012) में, यह विकल्प प्रोग्रामरों के लिए एक वास्तविक मानक है।

नींव

समानांतर कम्प्यूटिंग के संदर्भ में वेब सेवाएं समानांतर सबट्यूसर प्रदान करती हैं; और प्रोटोकॉल, सोप की तरह, अच्छा तुल्यकालन और संचार सुनिश्चित करता है। "कोई कार्य" नहीं: वेब सेवाओं को
मोटे-मोटे और शर्मनाक समानता के रूप में वर्गीकृत किया जा सकता है ।

जैसा कि कार्य बड़ा हो जाता है, यह कम महत्वपूर्ण "जटिलता बहस" बन जाता है, और संचार की मजबूती और अनुबंधों की दृढ़ता से अधिक प्रासंगिक हो जाता है।

Comments

मुझे नहीं लगता कि यह कुछ भी जोड़ता है। यह मूल प्रश्न या मेरे बाउंटी के तीन प्रश्नों का उत्तर नहीं देता है: किसी समस्या की कौन सी विशेषताएँ SOAP को बेहतर विकल्प बनाती हैं? SOAP क्या आसान / कठिन बनाता है? SOAP आपको वह करने की अनुमति देता है जो आप REST के साथ नहीं कर सकते हैं।

— सैम हसलर

चेतावनी के लिए धन्यवाद! ... वैसे मैं केवल एक "2012 की अद्यतन" (!) की कोशिश करता हूं, जो कि मुख्य बात है, क्योंकि "सुविधाओं" के बारे में सभी तर्कों को दोहराने की आवश्यकता नहीं है ... बेहतर विकल्प ... आसान / कठिन बना दें। .. बाकी के साथ नहीं कर सकते "। आप अन्य उत्तरों को नहीं देखते हैं? मेरे पास और 5 दिन हैं, शायद आपको "mmhuhues जवाब" के लिए एक काउंटरप्वाइंट देखने के लिए "सारांश / सारांश" की आवश्यकता है, यह केवल है? पुनश्च: मैं संपादन के बाद इस टिप्पणी को हटा दूंगा।

— पीटर क्रस

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

— सैम हस्लर

यही तो मैं नहीं चाहता। और मैं नहीं देखता कि कैसे WSDL प्रासंगिक है। WSDL SOAP या REST वेब सेवाओं का वर्णन कर सकता है, आप खुद का विरोधाभास करने लगते हैं।

— सैम हिटलर

"REST बनाम JSON-RPC" में समान चर्चा के लिए , stackoverflow.com/a/41686155/287948

— पीटर क्रूस

Answer 15

यह अति सूक्ष्म है।

यदि आपको अपनी सेवाओं के साथ अन्य सिस्टम इंटरफ़ेस की आवश्यकता है, तो बहुत सारे क्लाइंट SOAP के साथ अधिक खुश होंगे, "वेरीफिकेशन" की परतों के कारण आपके पास कॉन्ट्रैक्ट, WSDL और SOAP मानक हैं।

सिस्टम में कॉल करने के लिए दिन-प्रतिदिन के सिस्टम के लिए, मुझे लगता है कि SOAP बहुत अनावश्यक ओवरहेड है जब एक साधारण HTML कॉल करेगा।

Answer 16

मैं एक ही देख रहा हूं, और मुझे लगता है, वे अलग-अलग समस्याओं के लिए अलग-अलग उपकरण हैं ।

सरल वस्तु एक्सेस प्रोटोकॉल (एसओएपी) मानक एक एक्सएमएल भाषा है जो एक संदेश वास्तुकला और संदेश प्रारूपों को परिभाषित करता है, इसका उपयोग वेब सेवाओं द्वारा किया जाता है जिसमें ऑपरेशन का विवरण होता है। WSDL वेब सेवाओं का वर्णन करने और उन्हें एक्सेस करने के लिए XML- आधारित भाषा है। SMTP, HTTP, FTP आदि पर चलेंगे

प्रतिनिधि राज्य अंतरण (रेस्टफुल) वेब सेवाएँ। वे दूसरी पीढ़ी की वेब सेवाएँ हैं। प्रतिष्ठित वेब सेवाएँ, SOAP- आधारित सेवाओं की तुलना में HTTP के माध्यम से संचार करती हैं और XML संदेश या WSDL सेवा-एपीआई परिभाषाओं की आवश्यकता नहीं होती है। REST के लिए किसी मिडलवेयर की आवश्यकता नहीं है केवल HTTP समर्थन की आवश्यकता है। WADL मानक, REST XML, सादा पाठ, JSON, HTML आदि लौटा सकता है।

कई प्रकार के क्लाइंट के लिए सर्वर साइड को विकसित करने और पैमाने पर सक्षम करने के लिए रेस्टफुल वेब सेवाओं का उपभोग करना आसान है। ग्राहक सेवा के कुछ या सभी पहलुओं का उपभोग कर सकते हैं और इसे अन्य वेब-आधारित सेवाओं के साथ मैश कर सकते हैं।

1. REST मानक HTTP का उपयोग करता है, इसलिए यह क्लाइंट बनाने, एपीआई विकसित करने के लिए सरल है
2. REST XML, सादे पाठ, JSON, HTML जैसे कई अलग-अलग डेटा स्वरूपों की अनुमति देता है जहां SOAP केवल XML की अनुमति देता है।
3. REST में बेहतर प्रदर्शन और मापनीयता है।
4. आराम और कैश किया जा सकता है और साबुन नहीं हो सकता
5. अंतर्निहित त्रुटि हैंडलिंग जहां SOAP में कोई त्रुटि हैंडलिंग नहीं है
6. REST विशेष रूप से उपयोगी पीडीए और अन्य मोबाइल उपकरण हैं।

REST सेवाएँ मौजूदा वेबसाइटों के साथ एकीकृत करने में आसान हैं।

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

कॉम्प्लेक्स एपीआई के लिए एसओएपी अधिक उपयोगी होगा।

Answer 17

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

SOAP एक XML- आधारित प्रोटोकॉल है जो एक HTTP अनुरोध / प्रतिक्रिया के अंदर सुरंग है, इसलिए भले ही आप SOAP का उपयोग करते हैं, आप REST का भी उपयोग कर रहे हैं। इस बात पर कुछ बहस है कि क्या SOAP बुनियादी HTTP में कोई महत्वपूर्ण कार्यक्षमता जोड़ता है।

एक वेब सेवा को अधिकृत करने से पहले, मैं HTTP का अध्ययन करने की सलाह दूंगा। ऑड्स आपकी आवश्यकताएं हैं जिन्हें पहले से ही कल्पना की गई कार्यक्षमता के साथ लागू किया जा सकता है, इसलिए अन्य प्रोटोकॉल की आवश्यकता नहीं होगी।

Answer 18

मैं उसी मुद्दे को देख रहा हूं। मुझे लगता है कि वास्तव में REST त्वरित और आसान है और हल्के कॉल और प्रतिक्रियाओं के लिए अच्छा है और डीबगिंग के लिए बहुत अच्छा है (ब्राउज़र में URL पंप करने और प्रतिक्रिया देखने से बेहतर क्या हो सकता है)।

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

SOAP की सुंदरता यह है कि एक बार एक WSDL जारी किया जाता है तो व्यापार 'उनके तर्क अरुंड की संरचना कर सकता है जो कि इंटरफ़ेस में कोई भी परिवर्तन करने के लिए अनुबंध को सेट करेगा wsdl को बदल देगा। वहाँ manouvre के लिए कोई जगह नहीं है। आप उस WSDL के विरुद्ध सभी अनुरोधों को मान्य कर सकते हैं। हालांकि क्योंकि WSDL एक REST सेवा का ठीक से वर्णन नहीं करता है, इसलिए आपके पास संचार के लिए इंटरफ़ेस पर सहमत होने का कोई परिभाषित तरीका नहीं है।

व्यापारिक दृष्टिकोण से यह संचार को व्याख्या और परिवर्तन के लिए खुला छोड़ देता है जो एक बुरे विचार की तरह लगता है।

इस सूत्र में शीर्ष 'उत्तर' से प्रतीत होता है कि SOAP का अर्थ है सिंपल ऑब्जेक्ट-ओरिएंटेड एक्सेस प्रोटोकॉल, हालांकि विकी को देखते हुए O का मतलब ऑब्जेक्ट ऑब्जेक्ट-ओरिएंटेड नहीं है। वे अलग चीजें हैं।

मुझे पता है कि यह पोस्ट बहुत पुरानी है लेकिन मुझे लगा कि मुझे अपने निष्कर्षों के साथ जवाब देना चाहिए।

Answer 19

यह एक अच्छा सवाल है ... मैं आपको भटकाने का नेतृत्व नहीं करना चाहता, इसलिए मैं अन्य लोगों के उत्तरों के लिए खुला हूं जितना आप हैं। मेरे लिए, यह वास्तव में ओवरहेड की लागत के लिए नीचे आता है और एपीआई का उपयोग क्या है। मैं क्लाइंट सॉफ्टवेयर बनाते समय वेब सेवाओं का उपभोग करना पसंद करता हूं, हालांकि मुझे SOAP का वजन पसंद नहीं है। REST, मेरा मानना ​​है कि हल्का वजन है, लेकिन मुझे ग्राहक के दृष्टिकोण से इसके साथ काम करने में मजा नहीं आता है।

मैं उत्सुक हूं कि दूसरे क्या सोचते हैं।

Answer 20

यह जानने के लिए इस पॉडकास्ट को सुनें । अगर आप बिना सुने जवाब जानना चाहते हैं, तो ठीक है, इसका REST। लेकिन मैं वास्तव में सुनने की सलाह देता हूं।

Answer 21

मेरा सामान्य नियम यह है कि यदि आप एक ब्राउज़र वेब क्लाइंट को सीधे किसी सेवा से जोड़ना चाहते हैं तो आपको शायद REST का उपयोग करना चाहिए। यदि आप बैक-एंड सेवाओं के बीच संरचित डेटा पास करना चाहते हैं तो SOAP का उपयोग करें।

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

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

यह एक तरह से दुखद है, क्योंकि यह वास्तव में SOAP को एक खराब प्रतिष्ठा देता है क्योंकि अंतिम उत्पाद का उपयोग कैसे किया जाता है, इसे पूरे संदर्भ में प्रस्तुत किए बिना SOAP के फायदे दिखाना मुश्किल है।

Answer 22

SOAP वेब सेवाओं के लिए एक सेवा-उन्मुख दृष्टिकोण का प्रतीक है - एक वह तरीका जिसमें (या क्रियाएं) प्राथमिक तरीका है जो आप सेवा के साथ बातचीत करते हैं। REST एक संसाधन-उन्मुख दृष्टिकोण लेता है जिसमें ऑब्जेक्ट (या संज्ञा) केंद्र चरण लेता है।

Comments

(सी) आईबीएम ibm.com/developerworks/library/j-grails09168

Answer 23

किसी भी उन्नत SOAP के लिए "PHP-ब्रह्मांड" PHP समर्थन के साथ समझ में बड़ा समय बेकार है। जैसे ही आप बुनियादी जरूरतों को पार करते हैं, यहां तक ​​कि WS-Security या WS-RM कोई इनबिल्ट सपोर्ट को सक्षम करने के लिए आप http://wso2.com/products/web-services-framework/php/ जैसी किसी चीज़ का उपयोग कर समाप्त हो जाएंगे ।

SOAP लिफाफा निर्माण मुझे लगता है कि PHP में बहुत गड़बड़ है, जिस तरह से यह नामस्थान बनाता है, xsd: nil, xsd: anytype और पुराने स्टाइल साबुन सेवाएँ जो SOAP एन्कोडिंग का उपयोग करते हैं (भगवान जानते हैं कि कैसे अलग है) SOAP संदेशों में।

REST से चिपक कर इस सभी गड़बड़ी से बचें, REST वास्तव में कुछ भी बड़ा नहीं है जिसका उपयोग हम WWW की शुरुआत से करते आ रहे हैं। हमें केवल तभी पता चला जब यह http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm पेपर सामने आया, यह दिखाता है कि हम RestFul Services को लागू करने के लिए HTTP क्षमताओं का उपयोग कैसे कर सकते हैं। HTTP स्वाभाविक रूप से REST है, इसका मतलब यह नहीं है कि केवल HTTP का उपयोग आपकी सेवाओं को RESTFul बनाता है।

SOAP HTTP की मुख्य क्षमताओं की उपेक्षा करता है और HTTP को केवल परिवहन प्रोटोकॉल के रूप में मानता है, इसलिए यह सिद्धांत रूप में स्वतंत्र रूप से परिवहन प्रोटोकॉल है (व्यावहारिक रूप से ऐसा नहीं है कि आपने SOAP एक्शन हेडर के बारे में सुना है? यदि यह अभी Google नहीं है तो!)।

JSON अनुकूलन के साथ वृद्धि और HTML5 जावास्क्रिप्ट के साथ REST JSON के साथ परिपक्व होना सेवाओं से निपटने का सबसे आम तरीका बन गया है। JSON स्कीमा को भी परिभाषित किया गया है यदि आवश्यक हो तो WADL के साथ उद्यम स्तर के समाधान (अभी भी प्रारंभिक अवस्था में) के लिए उपयोग किया जा सकता है।

REST और JSON के लिए PHP समर्थन निश्चित रूप से मौजूदा इनबिल्ट SOAP समर्थन से बेहतर है।

SOA, WOA, ROA यहाँ कुछ और BUZZ शब्द जोड़ रहे हैं

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

जिस तरह से मैं विशेष रूप से डब्ल्यूएस-सुरक्षा युक्ति के लिए SOAP से प्यार करता हूं, यह एक अच्छी कल्पना है और अगर एंटरप्राइज़ JSON अनुकूलन में किसी को निश्चित रूप से JSON के लिए कुछ समान चीज़ों के साथ आने की आवश्यकता है, जैसे फ़ील्ड स्तर एन्क्रिप्शन आदि।

Answer 24

एक त्वरित बिंदु - ट्रांसमिशन प्रोटोकॉल और ऑर्केस्ट्रेशन;

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

यकीन नहीं है कि आप REST के साथ भी ऐसा कर सकते हैं - मुझे इंतजार है कि आप सही होंगे या कोर्स करेंगे! REST के साथ, सेवा परिभाषा को बदलें - इसके बारे में कुछ भी नहीं पता है जब तक कि यह 400 (या जो भी) वापस नहीं करता है।

Answer 25

यदि आप विभिन्न प्रणालियों और भाषाओं के बीच अंतर की तलाश कर रहे हैं, तो मैं निश्चित रूप से REST के लिए जाऊंगा। उदाहरण के लिए, मैंने .NET और Java के बीच SOAP काम करने में बहुत सी समस्याएं ली हैं।

Answer 26

मैं उनमें से कौन सा तेजी से कर रहे हैं के लिए एक बेंचमार्क बनाने के लिए! मैं यह परिणाम देखता हूं:

1000 अनुरोधों के लिए:

• REST ने 3 सेकेंड का समय लिया
• SOAP ने 7 सेकंड का समय लिया

10,000 अनुरोधों के लिए:

• REST ने 33 सेकंड का समय लिया
• SOAP ने 69 सेकेंड का समय लिया

1,000,000 अनुरोधों के लिए:

• REST ने 62 सेकंड का समय लिया
• SOAP ने 114 सेकंड का समय लिया

Answer 27

एक पुराना प्रश्न लेकिन आज भी प्रासंगिक है .... उद्यम स्थान में बहुत सारे डेवलपर्स अभी भी इसका उपयोग कर रहे हैं।

मेरे काम में IoT (इंटरनेट ऑफ थिंग्स) समाधानों को डिजाइन करना और विकसित करना शामिल है। जिसमें छोटे एम्बेडेड उपकरणों के लिए विकासशील कोड शामिल हैं जो क्लाउड के साथ संचार करते हैं।

यह स्पष्ट है कि REST अब व्यापक रूप से स्वीकृत और उपयोगी है, और वेब के लिए बहुत अधिक मानक मानक है, यहां तक ​​कि Microsoft के पास पूरे Azure में शामिल REST का समर्थन है। यदि मुझे SOAP पर भरोसा करने की आवश्यकता है तो मैं वह नहीं कर सकता जो मुझे करने की आवश्यकता है, जैसा कि बहुत अधिक बड़ा, भारी और कई एम्बेडेड उपकरणों के लिए कष्टप्रद है।

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

Answer 28

1. मेरे अनुभव से। मैं कहूंगा कि REST आपको पहले से निर्मित URL तक पहुँचने का विकल्प देता है। जैसे-> Google में एक शब्द खोज। उस URL को REST के लिए webservice के रूप में उपयोग किया जा सकता है। SOAP में, आप अपनी स्वयं की वेब सेवा बना सकते हैं और इसे SOAP क्लाइंट के माध्यम से एक्सेस कर सकते हैं।

2. REST पाठ, JSON, XML प्रारूप का समर्थन करता है। इसलिए दो अनुप्रयोगों के बीच संवाद करने के लिए अधिक बहुमुखी। जबकि SOAP संदेश संचार के लिए केवल XML प्रारूप का समर्थन करता है।