कोई SOAP आधारित सेवाओं के बजाय REST का उपयोग क्यों करेगा? [बन्द है]

153

बंद हो गया । इस प्रश्न पर अधिक ध्यान देने की आवश्यकता है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि यह इस पोस्ट को संपादित करके केवल एक समस्या पर केंद्रित हो ।

7 साल पहले बंद हुआ ।

इस प्रश्न को सुधारें

आज REST पर एक दिलचस्प डेमो में भाग लिया, हालाँकि, मैं एक भी कारण के बारे में नहीं सोच सकता था (और न ही किसी को प्रस्तुत किया गया था) क्यों REST वैसे भी SOAP आधारित सेवाओं के स्टैक की तुलना में उपयोग करने और कार्यान्वित करने के लिए बेहतर या सरल है।

ऐसे कुछ कारण हैं कि "वास्तविक दुनिया" में कोई भी SOAP आधारित सेवाओं के बजाय REST का उपयोग क्यों करता है?

web-services rest

— AngryHacker
स्रोत

37

वेब द्वारा सेवाओं आप सोप शैली वेब सेवाओं की बात कर रहे? क्योंकि जहाँ तक मुझे पता है कि आपके पास RESTful वेब सेवाएँ भी हो सकती हैं।

— जेम्स मैकमोहन

160

कम ओवरहेड (प्रत्येक कॉल को लपेटने के लिए कोई SOAP लिफाफा नहीं)

कम दोहराव (HTTP पहले से ही DELETE, PUT, GET, आदि जैसे परिचालनों का प्रतिनिधित्व करता है जिन्हें अन्यथा SOAP लिफाफे में दर्शाया जाना है)।

अधिक मानकीकृत - HTTP संचालन अच्छी तरह से समझा जाता है और लगातार संचालित होता है। कुछ एसओएपी कार्यान्वयनों को सूक्ष्मता मिल सकती है।

अधिक मानव पठनीय और परीक्षण योग्य (केवल ब्राउज़र के साथ SOAP का परीक्षण करने के लिए कठिन)।

XML का उपयोग करने की आवश्यकता नहीं है (वैसे आपको SOAP के लिए किसी भी तरह की आवश्यकता नहीं है लेकिन यह मुश्किल से समझ में आता है क्योंकि आप पहले से ही लिफाफे की पार्सिंग कर रहे हैं)।

पुस्तकालयों ने SOAP (प्रकार) को आसान बना दिया है। लेकिन जैसा कि मैंने उल्लेख किया है कि आप बहुत से अतिरेक को दूर कर रहे हैं। हाँ, सिद्धांत में SOAP अन्य ट्रांस्पोर्ट्स पर जा सकता है ताकि समान चीजों को करने वाली एक परत की सवारी से बचने के लिए, लेकिन वास्तव में आपके द्वारा किए गए सभी SOAP काम के बारे में HTTP पर खत्म हो जाएगा।

— केंडल हेल्मसटेटर गेलनर
स्रोत

1

मैं उस अंतर-प्लेटफ़ॉर्म SOAP संचार को जोड़ना चाहता हूँ जो कि PITA भी हो सकता है (SOAP के बिंदु का वह हिस्सा नहीं है!?)।

— जस्टिन बोजोनियर

7

HTTP इंफ्रास्ट्रक्चर के साथ भी बढ़िया काम कर रहा है - जैसे GET को अंतिम रूप से संशोधित और etags के उपयोग के साथ आक्रामक रूप से कैश किया जाता है

— जेम्स स्ट्रेचन

अपनी सेवाओं में एक सार्वभौमिक ग्राहक प्रदान करने के लिए वेब ब्राउज़रों के साथ काम करना भी बहुत मदद करता है :)

— जेम्स स्ट्रेचन

2

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

— हावर्ड मई

6

HTTP सिर्फ SOAP के रूप में मानकीकृत है, और अब तक लगभग लागू हो चुका है, इसलिए कार्यान्वयन वास्तव में बोर्ड भर में स्थिर हैं और वास्तव में इंटरऑपरेबल हैं। SOAP भी स्वाभाविक रूप से कम पठनीय होने जा रहा है यहां तक कि समान सामग्री भी दी जा रही है, क्योंकि लिफाफे की सामग्री में लिपटे हुए हैं। पिछले कुछ वर्षों में व्यवहार में मैंने जॉन्सन को HTTP पर सबसे अच्छा संयोजन के बारे में पाया है, बस होने के दौरान पर्याप्त पठनीय है। और भी अधिक कॉम्पैक्ट।

— केंडल हेल्मस्टेटर जेलर

36

RESTful सेवाएं SOAP आधारित (नियमित) सेवाओं की तुलना में उपभोग करने के लिए बहुत सरल हैं। इसका कारण यह है कि REST सामान्य HTTP अनुरोधों पर आधारित है, जो कि किए जा रहे अनुरोध के प्रकार (GET = retrive, POST = लिखना, DELETE = remove, आदि) से अनुमान लगाने में सक्षम बनाता है और पूरी तरह से स्टेटलेस है। दूसरी ओर आप तर्क दे सकते हैं कि यह कम लचीला है क्योंकि यह एक संदेश लिफाफे की अवधारणा के साथ दूर करता है जिसमें अनुरोध संदर्भ होता है।

मेरे अनुभव में एसओएपी को उद्यम के भीतर सेवाओं के लिए पसंद किया गया है और आरईएसटी को उन सेवाओं के लिए पसंद किया गया है जिन्हें सार्वजनिक एपीआई के रूप में उजागर किया गया है।

.NET फ्रेमवर्क में WCF जैसे टूल के साथ किसी सेवा को REST या SOAP के रूप में लागू करना बहुत तुच्छ है।

कुछ प्रासंगिक पढ़ने:

— एरिक स्कूनओवर
स्रोत

9

मेरी समझ यह है कि WSDL फ़ाइलों का उपयोग वेब सेवा विधियों को उजागर करने के लिए कक्षाएं उत्पन्न करने के लिए किया जा सकता है। निश्चित रूप से यह किसी फ़ंक्शन को कॉल करने के रूप में सेवाओं की खपत को आसान बनाता है? क्या आप अपना विचार कुछ और बता सकते हैं।

— हावर्ड मई

1

हॉवर्ड मई: मान लें कि आप केवल आदिम डेटाैटिप्स का उपयोग करके फ़ंक्शन कहते हैं, यह निश्चित रूप से सच है। लेकिन उस मामले में आप बिल्कुल बहस नहीं कर सकते हैं सोप बाकी की तुलना में आसान है। यदि आपके पास जटिल डेटाैटिप्स हैं, तो WSDL प्रसंस्करण एक ही WS स्टैक के साथ दो मशीनों के बीच ठीक काम कर सकता है। लेकिन आप अनिवार्य रूप से जैसे ही आप मिश्रण मिश्रण के मुद्दे होंगे। असंगतताओं को डीबग करने के लिए WSDL में खोदना आपके लिए एक बार इतना आसान होना बंद हो जाता है।

— जोसेफ होल्स्टेन

1

2014 में, लगभग हर मंच, यहां तक कि प्राचीन भी, WSDL का समर्थन करते हैं। प्रॉक्सी कक्षाएं एपीआई का उपयोग करके बहुत सरल बनाती हैं। हम एक धक्का सेवा को लागू कर रहे हैं और मैं आरईएसटी पर विचार कर रहा हूं, लेकिन मुझे वास्तव में कोई लाभ देखने में परेशानी हो रही है।

— जॉनऑपिनकर

13

मुझे लगता है कि जब आप कहते हैं "वेब सेवाओं" आप SOAP और WS- * मानकों के सेट का मतलब है। (अन्यथा, मैं बहस सकता है कि बाकी सेवाओं रहे हैं "वेब सेवाओं"।)

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

बेशक, एक बार जब आप बारीकियों में ड्रिल करते हैं, तो आपको पता चलता है कि दोनों तरीकों में अलग-अलग परिदृश्यों में ताकत है। क्या यह उन बारीकियों में आपकी रुचि है?

— ब्रूस
स्रोत

10

ओवरहेड अच्छी वास्तुकला के रूप में महत्वपूर्ण नहीं है।

REST एक प्रोटोकॉल नहीं है यह एक आर्किटेक्चर है जो अच्छे स्केलेबल डिज़ाइन को प्रोत्साहित करता है। यह अक्सर चुना जाता है क्योंकि आरपीसी में बहुत अधिक स्वतंत्रता आसानी से खराब डिजाइन का कारण बन सकती है।

अन्य कारण HTTP पर Restful प्रोटोकॉल की अनुमानित लागत है क्योंकि यह मौजूदा प्रौद्योगिकियों (मुख्य रूप से प्रॉक्सी) का लाभ उठा सकता है। आरपीसी प्रारंभिक लागत काफी कम है, लेकिन यह लोड तीव्रता के साथ काफी बढ़ जाती है।

— पायोत्र कजपला
स्रोत

7

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

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

— joelhardi
स्रोत

एक अच्छा जवाब है, लेकिन मैं असहमत हूँ कि SOAP का मतलब है कि आपके पास इंटरनेट-स्केल लोड-बैलेंसिंग नहीं हो सकता है।

— एचडीवी

7

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

— Piko
स्रोत

6

स्टीव विनोस्की का ब्लॉग और उनके नवीनतम लेख निश्चित रूप से मनोरंजक हैं। वह एक पूर्व कोरा गुरु है, जिसने मिक्सी हेनिंग के साथ इस विषय पर शायद सबसे अच्छी पुस्तक लिखी, "उन्नत कोरबा® प्रोग्रामिंग विथ + ++" । हालाँकि, उसने तब से अपने क्लाइंट / सर्वर के तरीकों की त्रुटि देखी है, और अब REST द्वारा कसम खाता है।

— जेसन ईथर
स्रोत

5

REST आपके गैर-परिवर्तनकारी संचालन (जो आमतौर पर GET क्रिया का उपयोग करता है) को कैश करने की अनुमति देता है । अर्थात्, क्लाइंट द्वारा कैश किया गया और / या प्रॉक्सी द्वारा कैश किया गया। यह एक बड़ी जीत हो सकती है!

— डेविड
स्रोत

8

वह बस 'HTTP का सही उपयोग कर रहा है', और REST नहीं।

— aehlke

3

REST मूल रूप से वेब सेवाओं को लागू करने का एक तरीका है। यह उन वेब सेवाओं को क्वेरी करने के लिए सही ढंग से HTTP का उपयोग करने का एक तरीका है, जिन्हें आप हिट करने की कोशिश कर रहे हैं।

http://www.xfront.com/Rest-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

— एरिक होल्शर
स्रोत

1

REST का HTTP से कोई लेना-देना नहीं है, और यह पूरी तरह से प्रोटोकॉल-स्वतंत्र है। हालांकि यह कुछ प्रकार की संसाधन-केंद्रित वेब सेवाओं के लिए अनुकूल है।

— aehlke

0

यह सुपर सिंपल और स्लिम है। आप इसे HTTP वर्ब के माध्यम से ब्राउज़र के साथ कर सकते हैं: GET। मुझे ऐसा कोई ब्राउज़र नहीं मिला जो मैन्युअल रूप से सामान्य HTTP POST अनुरोध को आसानी से कर सके

— रे लू
स्रोत

1

चेकआउट फिडलर। यह एक ब्राउज़र नहीं है, लेकिन यह HTTP POST के बिना कोड का निर्माण करने का एक शानदार तरीका है। fiddler2.com/fiddler2

— एरिक शूनओवर

मैं आमतौर पर चार्ल्स के साथ मौजूदा अनुरोध को संशोधित करने के साथ करता हूं। मेरे पास फिडलर भी है।

— रे लू

0

यहां एक डेटा बिंदु है: अमेज़ॅन REST और SOAP दोनों स्वरूपों में अपनी एपीआई प्रदान करता है और 85% उपयोग REST है।

REST को लागू करना आसान है, समझने में आसान और उच्च प्रदर्शन।

— pbreitenbach
स्रोत

7

क्या आपके पास अपने "उच्च प्रदर्शन" बयान के लिए कोई संदर्भ है?

— जेम्स मैकमोहन

3

आपको 85% उपयोग कहां से मिला? यह जानना बहुत अच्छा है (अगर मैं सबूत देख सकता हूं)

— schmoopy

3

मैन्युअल रूप से एक एपीआई विनिर्देश, मुद्रण पृष्ठों आदि को पढ़ना, "राइट क्लिक, एड सर्विस रेफरेंस" की तुलना में लागू करना आसान है? (

— वीएस २०१०

@schmoopy Amazon ब्लॉग से: aws.typepad.com/aws/2005/09/rest_vs_soap.html

— joerage