किसी वेब सेवा को SOAP या REST सेवा के रूप में उजागर करने के लिए निर्णायक कारक क्या हैं?

Question

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

तो SOAP का अतिरिक्त ओवरहेड / जटिलता आपको क्या देता है, आपको इसकी आवश्यकता कब होती है और इसके बिना आपको कब और क्या करना चाहिए?

Answer 1

मैंने पहले एक REST API लागू किया है और मुझे यह वास्तव में पसंद आया है। सामान्य तौर पर जब आप SOAP पर REST को कार्यान्वित करते हैं , तो आपका क्लाइंट / सर्वर अधिक ऑर्थोगोनल अर्थ है कि आप अपने क्लाइंट (एस) को प्रभावित किए बिना सर्वर को बहुत अधिक स्वतंत्र रूप से बदल सकते हैं। यह orthogonality HTTP क्रियाओं के माध्यम से एक अधिक सार और पहले से ही अच्छी तरह से परिभाषित संचार का उपयोग करने के कारण है। इसके अलावा, आपके REST प्रतिक्रियाओं में एम्बेडेड हाइपरलिंक्स का उपयोग आपके एपीआई को अपेक्षाकृत मुफ्त दर्द को बढ़ाने और बढ़ने में आसान बनाता है। ग्राहकों को इन एम्बेडेड लिंक का पालन करने के लिए माना जाता है कि नए संसाधनों के लिए मानव एक वेबपेज पर अधिक जानकारी के लिए 'ड्रिल डाउन' के लिंक का पालन करेगा।

इसके साथ ही, मेरे पास कुछ सहकर्मी थे जिन्हें बताया गया था कि उन्हें SOAP का उपयोग करना था और उन्होंने हर समय इसकी शिकायत की। इसलिए मैंने दोनों पर विस्तार से शोध किया।

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

SOAP जाने का सबसे तेज़ तरीका हो सकता है जब आपको क्लाइंट के लिए छोटे एपीआई या जल्दी से दो की आवश्यकता हो और आप स्केलेबिलिटी के बारे में बहुत चिंतित न हों। यदि आप एक ऐसा आर्किटेक्चर नहीं रखते हैं जो संसाधनों के आसपास संरचित है , तो यह आपको बेहतर तरीके से फिट हो सकता है , क्योंकि आपके ऐप को पुनर्गठन करने में कुछ समय लग सकता है।

Comments

आप संसाधन प्रतिमान और राज्य की कमी के कारण कैशिंग प्राप्त करते हैं, HTTP के कारण नहीं।

— डायटबुद्ध

@dietbuddha HTTP आपको मुफ्त में कार्यान्वयन देता है।

— जैकब रायहले

Answer 2

यह एक मामूली बात हो सकती है, लेकिन REST पूरी तरह से HTTP पर आधारित है।

SOAP को HTTP की आवश्यकता नहीं है, और आप जो भी परिवहन पसंद करते हैं उसका उपयोग करने के लिए स्वतंत्र हैं।

SOAP संदेशों को अतुल्यकालिक और मज़बूती से रूट किया जा सकता है जबकि REST बहुत अधिक समकालिक प्रतिमान है।

REST आपको कुछ भी नहीं बताता है कि आप जो डेटा भेज रहे हैं और प्राप्त कर रहे हैं वह कैसा दिखना चाहिए। WADL है, लेकिन ज्यादातर आप एपीआई के दस्तावेज के सही होने पर भरोसा करते हैं। SOAP में डेटा विवरण कम त्रुटि प्रवण बनाने के लिए XML तकनीकों का सर्कस है। डब्ल्यूएसडीएल, स्कीमा ...

दिन के अंत में REST मूल रूप से आपको HTTP पर आधारित एक फ़ाइल सिस्टम देता है। यदि आपका सिस्टम उस प्रतिमान में फिट हो सकता है - तो यह एक अच्छा विकल्प हो सकता है।

Comments

मल्टीपल ट्रांसपोर्ट का उल्लेख करने के लिए +1। यदि आपको वास्तव में ट्रांसपोर्ट-एग्नॉस्टिक प्रोटोकॉल की आवश्यकता है (जो एसएमटीपी या इसी तरह के माध्यम से ऑपरेशन का समर्थन करता है), तो आरईएसटी बाहर है। आमतौर पर HTTP काफी अच्छा है, लेकिन ...

— sleske

मैं यह नहीं देखता कि REST HTTP से कैसे बंधा है? यह कार्यान्वयन विस्तार है। अधिकांश REST कार्यान्वयन HTTP पर जाते हैं, लेकिन मैं यह नहीं देखता कि मैं FTP जैसे अन्य प्रोटोकॉल पर REST को लागू क्यों नहीं कर सका।

— एडलोरजो

REST संचार को किसी विशेष प्रोटोकॉल रेफरी तक सीमित नहीं करता है: ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

— nmtoken

Answer 3

तो SOAP का अतिरिक्त ओवरहेड / जटिलता आपको क्या देता है, आपको इसकी आवश्यकता कब होती है और इसके बिना आपको कब और क्या करना चाहिए?

दोनों के बीच सबसे बड़ा अंतर यह है कि REST को स्टेटलेस माना जाता है, जहां-जैसे SOAP नहीं है । वास्तव में कई रीस्ट कार्यान्वयन वास्तव में OAuth जैसे कुछ के माध्यम से सत्र में कुछ राज्य को लागू करते हैं।

एक और अंतर है REST बहुत "संसाधन" या संज्ञा उन्मुख है । आप CRUD संचालन के माध्यम से संसाधनों के साथ बातचीत करते हैं। जो कुछ भी इस प्रतिमान को फिट नहीं करता है वह बोझिल और अजीब हो जाता है।

दूसरी ओर SOAP सिर्फ एक RPC (दूरस्थ प्रक्रिया कॉल) प्रोटोकॉल है । यह एक प्रतिमान के साथ नहीं आता है, यह सिर्फ परिवहन परत है।

Comments

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

— JensG

Answer 4

REST पोस्ट का भी उपयोग करता है। वास्तव में जब REST http वर्ब्स का उपयोग करते हैं तो आपको बताते हैं कि ऑपरेशन क्या चल रहा है।

REST और SOAP इंटरनेट पर डेटा पास करने के विभिन्न मानक हैं।

दोनों का उपयोग करने के बाद, मैं आम तौर पर SOAP के बजाय REST का उपयोग करने की सलाह देता हूं जब तक कि आपको नहीं पता कि जो लोग आपकी वेब सेवा का उपभोग करने जा रहे हैं वे .net और Visual Studio का उपयोग कर रहे हैं। आमतौर पर .net VS के अलावा एक REST वेब सेवा का उपभोग करना बहुत आसान है जो आपके SOAP का उपयोग करते समय आपके लिए अधिकांश काम करता है।

Comments

जावा में भी अच्छा सोप सपोर्ट है।

Answer 5

एक बात जिसका मैं उल्लेख करूंगा, वह है इंटरऑपरेबिलिटी - यदि आप .NET में लिखे ऐप से अपनी सेवा को कॉल करने जा रहे हैं और सर्वर जावा (या किसी अन्य संयोजन) में लिखा गया है, तो REST के लिए जाएं। मैंने SOAP कार्यान्वयनों के बीच बहुत कम असंगतताएं देखी हैं ताकि इसे और अधिक समझने पर परेशान किया जा सके।

Comments

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

— जेन्सजी

Answer 6

यदि आप अपने अनुप्रयोगों की आवश्यकताओं के विरुद्ध SOAP और REST को मापने में आपकी सहायता के लिए एक सरल, दृश्य मार्गदर्शिका चाहते हैं ...

विजय प्रसाद गुप्ता ने सरल, सहायक प्रवाह-चार्ट को एक साथ रखा है।

फ्लो चार्ट के लिए सीधा लिंक: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit

लिंक से लिंक करें: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-prococol-for-your-needs

Comments

यह वास्तव में एक बहुत अच्छा प्रवाह है। मुझे आश्चर्य हुआ कि यहाँ एक भी उत्तर REST पर SOAP के लाभों को संबोधित नहीं करता है। हालांकि यह फ़्लोचार्ट करता है। मुझे लगता है कि मैं फ़्लोचार्ट को एक छवि के रूप में शामिल कर सकता हूं, हालांकि इसे लिंक करने के बजाय, यह सुनिश्चित करने के लिए कि यह उत्तर के साथ चिपक जाता है?

— 14

Answer 7

अब यह 2015 है। मुझे आशा है कि SOAP अब तक मर चुका है, लेकिन यह अभी भी एक बुरी गंध की तरह है। कुछ भी लेकिन "उदाहरण" अनुप्रयोगों के लिए सबसे बुनियादी, एक SOAP सेवा के साथ एकीकरण चुनौतियों से भरा है। यह एक जटिल वास्तुकला है, जिसमें कई स्तरों पर कई विकल्प होते हैं, कई कार्यान्वयन और सूक्ष्म (और इतना सूक्ष्म नहीं) असंगतियों की quirks के साथ संयुक्त। मैंने इसके साथ एक भी अच्छा अनुभव नहीं किया है। दूसरी ओर, REST एक हवा है: हर कोई HTTP को समझता है। ज्यादातर मामलों के लिए, JSON में XML InfoSet की तुलना में अधिक उपयोगिता है।

आपको SOAP की जटिलता का पता लगाने के लिए, अपने प्रोजेक्ट में SOAP लाइब्रेरी को एकीकृत करने का प्रयास करें। जावा के लिए, सबसे बुनियादी Apache Axis2 क्लाइंट (सरल ADB डेटा बाइंडिंग का उपयोग करके) 23 नए JAR में खींचता है। तेईस! पुस्तकालय ब्लोट के 20 एमबी। सीएक्सएफ समान है: 21 जार, जब मैंने आखिरी बार गिनती की थी।

यदि आप वास्तव में चाहते थे, तो आप एक साधारण HTTP लाइब्रेरी के साथ REST कर सकते हैं।

Comments

यह एक शेख़ी की तरह अधिक पढ़ता है, देखें कैसे जवाब दें

— gnat

आप सही हे। क्षमा करें, मैं उस समय SOAP सूप में अवाश कर रहा था: D

— कॉर्नेल मैसन

हमें 90 के दशक में CORBA / IDL के साथ भी यही शिकायत थी। फिर अचानक "सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल" .. यह सरल होगा! बढ़िया रहेगा! यह तेजी से होगा। दस साल बाद, इसे बहुत जटिल माना जाता है। JSON (IMAO वास्तव में छात्र लैब सेटिंग्स में डेटा ट्रांसफर संचालन के लिए एक वर्ग पहिया है या प्रतिबंधित है "मुझे पता है कि मैं क्या कर रहा हूं" त्वरित फिक्स स्थितियों) और रेस्टफुल ऑप्स। कुल्ला, दोहराएं ...

— डेविड टोनहोफर

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

— Maaartinus