xml वेब सेवाओं के लिए एसओएपी या आरईएसटी?




web-services rest (23)

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

बाउंटी-संपादित करें:

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


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

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


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


2012 के प्रश्न के लिए त्वरित कमी

क्षेत्र जो आरईएसटी वास्तव में अच्छी तरह से काम करता है:

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

  • पूरी तरह से स्टेटलेस ऑपरेशंस। यदि किसी ऑपरेशन को जारी रखने की आवश्यकता है, तो आरईएसटी सबसे अच्छा तरीका नहीं है और एसओएपी बेहतर फिट हो सकता है। हालांकि, अगर आपको स्टेटलेस सीआरयूडी (बनाएं, पढ़ें, अपडेट करें और हटाएं) ऑपरेशन की आवश्यकता है, तो आरईएसटी है।

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

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

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

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

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

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


An old question but still relevant today....due to so many developers in the enterprise space still using it.

My work involves designing and developing IoT (Internet of Things) solutions. Which includes developing code for small embedded devices that communicate with the Cloud.

It is clear REST is now widely accepted and useful, and pretty much the defacto standard for the web, even Microsoft has REST support included throughout Azure. If I needed to rely on SOAP I could not do what I need to do, as is just too big, bulky and annoying for small embedded devices.

REST is simple and clean and small. Making it ideal for small embedded devices. I always scream when I am working with a web developer who sends me a WSDLs. As I will have to begin an education campaign about why this just isn't going to work and why they are going to have to learn REST.


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

एसओएपी, पेशेवरों और विपक्ष

एसओएपी 1.2 के बारे में, "आरईएसटी" की तुलना करते समय फायदे और कमीएं ... ठीक है, 2007 के बाद से आप डब्लूएसडीएल के साथ आरईएसटी वेब सेवाओं का वर्णन कर सकते हैं और एसओएपी प्रोटोकॉल का उपयोग कर सकते हैं ... यानी, यदि आप थोड़ा कठिन काम करते हैं, तो सभी डब्ल्यू 3 सी मानकों वेब सेवा प्रोटोकॉल ढेर रीस्ट हो सकता है !

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

  • एसओएपी-आरईएसटी (= " रीस्ट -एसओएपी"): जैसा कि एल । मंडल द्वारा दिखाया गया है , डब्लूएसडीएल 2 एक आरईएसटी webservice का वर्णन कर सकता है, और, अगर हमें लगता है कि उदाहरण एक्सएमएल को एसओएपी में लिफाफा किया जा सकता है, तो सभी कार्यान्वयन "SOAP-REST" होंगे ।

  • गैर-एसओएपी-आरईएसटी : कोई भी आरईएसटी वेब सेवा जो एसओएपी नहीं हो सकती ... यानी, अच्छी तरह से ज्ञात आरईएसटी उदाहरणों का "9 0%" है। कुछ एक्सएमएल का उपयोग नहीं करते हैं (उदा। सामान्य AJAX RESTs इसके बजाय JSON का उपयोग करते हैं), कुछ SOAP शीर्षलेख या नियमों के बिना, किसी अन्य XML strucutures का उपयोग करते हैं। पीएस: अनौपचारिकता से बचने के लिए, हम तुलना में martinfowler.com/articles/richardsonMaturityModel.html अनुमान लगा सकते हैं।

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

  • गैर-रीस्ट-एसओएपी : कोई भी एसओएपी वेब सेवा जो आरईएसटी नहीं हो सकती ... यानी, अच्छी तरह से ज्ञात एसओएपी उदाहरणों का "9 0%" है।

  • गैर-पूर्वोत्तर-SOAP : हाँ, "वेब सेवाओं मॉडलिंग" के ब्रह्मांड में अन्य चीजें शामिल हैं (उदा। XML-RPC )।

आरईएसटी कंडेशंस में एसओएपी

तुलनात्मक चीजों की तुलना करना: गैर-एसओएपी-आरईएसटी के साथ SOAP-REST

पेशेवरों

कुछ शर्तों को समझाते हुए,

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

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

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

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

लोकप्रियता से पेशेवरों को छंटनी,

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

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

  • मजबूती : एसओएपी शीर्षकों का बीमा, @ जॉन सैंडर्स (8 वोट)।

कान्स

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

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

एसओएपी के साथ मॉडलिंग सेवाएं

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

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

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

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

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

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

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

संदर्भ

ऐतिहासिक

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

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

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

नींव

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

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


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

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

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

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

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

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

एसओए, डब्ल्यूओए, आरओए में कुछ और बुज़ शब्द जोड़ना

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

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

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


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

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

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

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

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

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


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

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

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


आरईएसटी एसओएपी से मूल रूप से अलग प्रतिमान है। आरईएसटी पर एक अच्छा पठन यहां पाया जा सकता है: मैंने अपनी पत्नी को आरईएसटी कैसे समझाया

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

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

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


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

for 1000 requests :

  • REST took 3 second
  • SOAP took 7 second

for 10,000 requests :

  • REST took 33 second
  • SOAP took 69 second

for 1,000,000 requests :

  • REST took 62 second
  • SOAP took 114 second

एसओएपी के पास वर्तमान में बेहतर टूल्स का लाभ है, जहां वे सेवा परत दोनों के लिए बॉयलरप्लेट कोड उत्पन्न करेंगे और साथ ही किसी भी दिए गए डब्लूएसडीएल से ग्राहकों को उत्पन्न करेंगे।

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


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


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


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

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

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

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

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

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

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

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


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

  1. आरईएसटी पाठ, जेएसओएन, एक्सएमएल प्रारूप का समर्थन करता है। इसलिए दो अनुप्रयोगों के बीच संचार के लिए अधिक बहुमुखी। जबकि एसओएपी संदेश संचार के लिए केवल एक्सएमएल प्रारूप का समर्थन करता है।

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

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

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

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


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

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


आरईएसटी एक वास्तुकला है, एसओएपी एक प्रोटोकॉल है।

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

आप एक आरईएसटी आवेदन में एसओएपी लिफाफे भेज सकते हैं।

एसओएपी स्वयं वास्तव में बहुत ही बुनियादी और सरल है, यह इसके ऊपर WSS- * मानक है जो इसे बहुत जटिल बनाता है।

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

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

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

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


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


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

आरईएसटी हर जगह लागू किया गया है, सरल, सरल, मानकों की तुलना में अधिक 'मानक') तेज़ और आसान है। आरईएसटी का प्रयोग करें।


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

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

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

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

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

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

क्या मुझे जाना चाहिए?


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

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

सुनिश्चित नहीं है कि आप आरईएसटी के साथ ऐसा ही कर सकते हैं - मैं सही या पाठ्यक्रम की प्रतीक्षा कर रहा हूं! आरईएसटी के साथ, सेवा परिभाषा को बदलें - इसके बारे में कुछ भी नहीं जानता जब तक कि यह 400 (या जो कुछ भी) नहीं लौटाता।


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

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

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

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

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

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





soap