मैं बाकी सवालों के विशेष रूप से यहाँ बनाम सोप द्वारा दिए गए जवाब से संतुष्ट नहीं कर रहा हूँ: Performance of SOAP vs. XML-RPC or RESTएसओएपी बनाम आरईएसटी: व्यावहारिक केस स्टडीज?
क्योंकि यह सिर्फ सामान्य दार्शनिक जवाब और कुछ अध्ययन के मामलों के साथ व्यावहारिक नहीं जवाब है।
कोई भी सटीक मामलों को तब तक दे सकता है जब साबुन आराम से अधिक उपयुक्त होगा, खासकर प्रदर्शन बिंदु के लिए?
अपडेट: मुझे लगता है कि आरईएसटी युद्ध जीत रहा है।
आप एक लेख बाकी और सोप यहाँ की तुलना पा सकते हैं:
लेखक निष्कर्ष लग रहा था - * लंबे जीवनकाल और उन्नत क्यूओएस आवश्यकताओं के साथ व्यावसायिक उद्यम अनुप्रयोग एकीकरण परिदृश्य में वेब सेवाएं
व्यक्तिगत रूप से मुझे "व्यावसायिक उद्यम" जैसी शब्दावली पसंद नहीं है क्योंकि यह ढीला और अनौपचारिक है। हालांकि मेरी राय में लेखकों ने लेख में कुछ अच्छे अंक दिए। हो सकता है कि समाप्त करने के लिए और कुछ स्वयं के विचारों को देने के लिए:
आप एपीआई सार्वजनिक बनाना चाहते हैं - RESTful तरह से करते हैं। क्यूं कर? क्लाइंट एप्लिकेशन के लिए उपयोग करना आसान है, इसलिए यह आपकी सेवा को और अधिक लोकप्रिय बना देगा। उदाहरण के लिए अमेज़न दोनों आराम और सोप एपीआई उजागर किया गया है, लेकिन उनके उपयोगकर्ताओं के 85% बाकी संस्करण को चुना है Amazon API - SOAP vs. REST
उपयोग साबुन और WS- * ढेर यदि आप पैदा करेगा (या आप बनाने की प्रक्रिया के कुछ नियंत्रण) आपकी सेवाओं के उपभोक्ता और उत्पादक दोनों और आपको डब्ल्यूएस- * की उन्नत सुविधाओं की आवश्यकता है। इसके लिए शायद अधिक संसाधनों की आवश्यकता होगी क्योंकि एसओएपी अनुप्रयोग "भारी" होते हैं (अधिक सुविधाएं, लेकिन अधिक परिष्कार भी)।
प्रदर्शन पर विचार करना आरईएसटी तेजी से हो सकता है (संदेश निश्चित रूप से कम हैं और आपको एक्सएमएल पार्स करने की आवश्यकता नहीं है)।
आशा है कि इससे मदद मिलेगी।
फ्लैश क्लाइंट के आपके उदाहरण में - विवरण जानने के बिना वास्तव में बताना मुश्किल है, हालांकि अगर किसी को इस सुरक्षा और डब्ल्यूएस- * की लेनदेन संबंधी सुविधाओं की आवश्यकता नहीं है, तो मुझे लगता है कि आरईएसटी बिल्डिंग का निर्माण सरल और तेज़ होगा।
टिप्पणी करने के लिए
मैं साबुन का प्रयोग करना चाहिए क्योंकि मैं तो "पेशेवर उद्यम"
और निश्चित रूप से यह मानते हुए कि कहा जाता है कि अपनी पसंद वास्तव में तय नहीं किया गया है में हूँ उत्तर देना बड़े सॉफ्टवेयर विक्रेताओं द्वारा।
एसओएपी बड़े उद्यमों के लिए उपयुक्त है क्योंकि यह अधिक औपचारिक दृष्टिकोण को प्रोत्साहित करता है। यह विनिर्देश प्रदान करता है, जो बहुत बड़े हैं, इसलिए आपके डेवलपर्स को उन्हें सीखने के लिए समय की आवश्यकता हो सकती है और शायद कुछ पेशेवर प्रशिक्षण भी -> इसलिए कंपनियों के संसाधनों को खर्च करना। यह उपकरण भी प्रदान करता है - और वे सभी खुले स्रोत नहीं हैं, इसलिए इसका अतिरिक्त संसाधन भी हो सकते हैं। लेकिन यदि आपकी टीम सेवाओं को एकीकृत करने के इस तरीके को सीख लेगी तो यह संभवतः कुशल होगी और परिणामी कोड उच्च गुणवत्ता वाला होगा।
इसके विपरीत आरईएसटी विकासशील अनुप्रयोगों का एक दर्शन है। तो, कोई विशाल विनिर्देश नहीं, कोई विशेष उपकरण नहीं। कोई संसाधन खर्च नहीं। यदि आपके पास अच्छे प्रोग्रामर की एक छोटी सी टीम है तो यह अच्छा काम कर सकता है - यदि वे बुनियादी सिद्धांतों को जानते हैं तो उन्हें कई दिशानिर्देशों की आवश्यकता नहीं होगी। दुर्भाग्य से चीजों को गलत करना भी आसान है।
विचार करने की एक और बात यह है कि अनुप्रयोगों का आकार - एपीआई जितना अधिक समृद्ध होगा, उतनी अधिक सेवाएं जिन्हें आप एकीकृत करना चाहते हैं, उतना ही कठिन होगा। छोटे एसओएपी आवेदन का निर्माण शायद एक अच्छा विचार नहीं होगा - पूरे ओवरहेड और प्रवेश लागत बहुत अधिक है।
आपको अपनी परियोजना के लिए पेशेवरों और विपक्ष का मूल्यांकन करने की आवश्यकता है। मुझे लगता है कि सभी विवरण जानने के बिना सिफारिश देना असंभव है।
और अंत में - इसका उचित तर्कों के साथ कुछ भी नहीं है लेकिन राजनीति के साथ और कुछ भी नहीं है। मुझे लगता है कि प्रबंधन स्तर के लोगों को डब्ल्यूएस- * स्टैक और एसओएपी पसंद है (इसमें "बड़े उद्यम" का समर्थन है, इसलिए उनके लिए उनके चयन को औचित्य देना आसान है)। दूसरी ओर अकादमिक पृष्ठभूमि से लोग [1] आरईएसटी पसंद करते हैं - क्योंकि अभी भी बहुत सारे शोध हैं जो क्षेत्र में आयोजित किए जा सकते हैं।
[1] मैं बीच में कहीं हूँ, इसलिए मैं अवलोकन कर सकते हैं दोनों व्यवहार ;-)
प्रदर्शन निर्णायक कारक नहीं है।
सबसे पहले मुझे कहना चाहिए कि एक एसओएपी-बनाम आरईएसटी प्रश्न पूछना थोड़ा छोटा है, क्योंकि एसओएपी एक एक्सएमएल लिफाफा प्रारूप है, और आरईएसटी एक वास्तुकला है। तो मैं थोड़ा सा अनुमान लगाऊंगा और मान लींगा कि आप वास्तव में SOAP-vs-POX या SOAP-vs-JSON या SOAP-vs-पर कुछ अन्य डेटा स्वरूपण दृष्टिकोण पर विचार कर रहे हैं।
निर्णय लेने वाला कारक यह होना चाहिए:
क्या आपको अब भविष्य में, एसओएपी लिफाफा की आवश्यकता है या आपको इसकी आवश्यकता होगी?
एसओएपी लिफाफा अन्य चीजों के साथ ढांचे-प्रदान की गई एन्क्रिप्शन, digsig, रूटिंग, और प्राधिकरण जांच जैसी चीजों की अनुमति देता है। आप निश्चित रूप से, आरईएसटी (या अधिक सटीक रूप से, सादे-पुराने-एक्सएमएल, या जेएसओएन, आदि के साथ उन चीजों को कर सकते हैं) लेकिन ऐसा करने के लिए आपको खुद को और अधिक काम करना होगा।
यदि प्रदर्शन - जो भी आप इसका मतलब मानते हैं - वास्तव में आपका # 1 मानदंड है, तो आपको शायद एसओएपी और पीओएक्स छोड़ना चाहिए और प्रोटोबफ्स या प्रदर्शन के लिए अनुकूलित कुछ और स्थानांतरित करना चाहिए। यह धारावाहिक और तेज़ी से संचार करने के लिए तेज़ हो सकता है।
यदि आपको लगता है यह जवाब है, "बहुत दार्शनिक" और आप वास्तव में कड़ी मेहनत आंकड़े, ठीक है, तो मुझे लगता है कि आप कुछ परीक्षण का संचालन करने की आवश्यकता होगी चाहते हैं। आपके द्वारा चुने गए टूलकिट्स, संदेशों का आकार, और अतिरिक्त डेटा सेवाओं (जैसे एन्क्रिप्शन और इसी तरह) पर वास्तविक perf बहुत भिन्न होगा। लेकिन अंत में, perf किसी भी तरह से निर्णायक नहीं होना चाहिए, या नहीं होना चाहिए।
यदि आपका SOAP टूलकिट उपयोग करने में 20% आसान है। डीबग करें, और अपने POX टूलकिट के रूप में बनाए रखें, फिर प्रदर्शन के बावजूद आपको SOAP का उपयोग करना चाहिए। लोग (कोडर, आर्किटेक्ट्स, टेस्टर्स) इन दिनों सीपीयू और नेटवर्क की तुलना में अधिक महंगा हैं। यदि आवश्यक हो, तो आप हमेशा एक और 2 सीपीयू, या एक बड़ा नेटवर्क खरीद सकते हैं, और यदि आपका डिज़ाइन सही है। लेकिन यदि आप अपने ढांचे का उपयोग करना मुश्किल है, या यदि यह आपके लोगों को दूर चला जाता है, तो आप किसी भी कीमत पर 20% कम समय का विकास नहीं कर सकते हैं। जब तक आप भू-पैमाने नेटवर्क नहीं चला रहे हैं, तो आप नेटवर्क के बजाय लोगों के लिए अनुकूलित करने के लिए बेहतर प्रदर्शन करेंगे।
मुझे यह पसंद है और बस जोड़ना होगा कि सभी भू-पैमाने नेटवर्क छोटे शुरू कर दिया। यदि आप अपने आप को भू-पैमाने पर ले जाते हैं, तो आपके पास उन लोगों को किराए पर लेने के लिए संसाधन होंगे जो विशेष रूप से नेटवर्क यातायात के लिए विशेषज्ञ की सहायता कर सकते हैं। मुझे लगता है कि "20% कम विकास का समय नहीं खरीद सकता" – jcolebrand
मैं सहमत नहीं हूं कि "लोग अधिक महंगी हैं" या कम से कम यह आपके उद्यम पर्यावरण और परियोजना पर निर्भर करता है। यदि यह साइट पर लाखों उपयोगकर्ताओं के साथ एक बड़ा कॉर्पोरेट है, तो यह एक बड़ा सौदा नहीं होगा। बड़ा सौदा है: प्रदर्शन वास्तव में सुधार होगा। यदि हां इसे लागू करने का प्रयास करें। तैनाती के लिए यह कई अन्य विभागों की वजह से एक और कहानी है लेकिन यह कीमत का सवाल नहीं है :) आपके उत्तर के लिए धन्यवाद। – user310291
मुझे लगता है कि निष्पादन निर्णायक कारक है केवल तभी जब यह परिमाण भिन्नता का क्रम है, जो यहां नहीं है। हम थोड़ा अधिक ओवरहेड या थोड़ा कम ओवरहेड बात कर रहे हैं, ऐसा कुछ भी नहीं है जो किसी अन्य चीज की लागत पर प्रदर्शन पर जुनून करने के लिए पर्याप्त पर्याप्त तरीके से स्केलेबिलिटी को प्रभावित करेगा। –
अच्छा जवाब, लेकिन "ग्राहक" शब्द के उपयोग से सावधान रहें। यदि आपका मतलब है, तो आप सही हैं, "जावास्क्रिप्ट क्लाइंट सीधे सेवा से बात करने के लिए XmlHttp का उपयोग कर रहा है", लेकिन यदि आपका क्लाइंट सेवा से बात करने के लिए जावास्क्रिप्ट प्रॉक्सी कक्षाओं का उत्पादन करने के लिए टूल का उपयोग करता है तो इतना नहीं। –
आपके विचार के लिए धन्यवाद। उपरोक्त लेखों के मुताबिक, मुझे साबुन का उपयोग करना चाहिए क्योंकि मैं तथाकथित "पेशेवर उद्यम" में हूं। लेकिन मुझे पता है कि तथाकथित पेशेवर कभी-कभी "विक्रेताओं को लक्षित उद्यम" का अर्थ है, जहां तकनीकी विकल्प पूरी तरह से तकनीकी कारणों से वाणिज्यिक हितों से अधिक निर्धारित होते हैं, इसलिए मैं सवाल पूछ रहा हूं :) – user310291