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




web-services rest (19)

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

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

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

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


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, अच्छा सिंक्रनाइज़ेशन और संचार सुनिश्चित करता है। "कोई कार्य नहीं": वेब सेवाओं को वर्गीकृत किया जा सकता है
मोटे अनाज और शर्मनाक समांतरता

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


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

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

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

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


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

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

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


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

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


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


किसी भी उन्नत 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

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


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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

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


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

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

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


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

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

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

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

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

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


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

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 और Java के बीच SOAP को काम करने की कोशिश करने में मुझे बहुत सारी समस्याएं आई हैं।


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

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


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

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


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


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

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




soap