प्रतिनिधि राज्य हस्तांतरण (REST) ​​और सरल वस्तु पहुंच प्रोटोकॉल (SOAP)

Question

क्या कोई समझा सकता है कि सादे अंग्रेजी में REST और SOAP क्या है ? और वेब सेवा कैसे काम करती है?

Comments

REST और SOAP वेब सेवाओं को समझने के लिए आपको इस PDF को पढ़ना होगा ।

— ललित कुमार मौर्य

आप इस ब्लॉग की जाँच कर सकते हैं javapapers.com/web-service/rest-vs-soap

— spideringweb

क्या मैं रीस्ट

— फिलिप

वेब सेवाओं के लिए SOAP या REST

— नवाफल

@PhilipCouling मैं किसी भी पीएचडी शोध प्रबंध को सामान्य अंग्रेजी नहीं कहूंगा ...

— stt106

Answer 1

SOAP और REST के बारे में सरल व्याख्या

SOAP - "सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल"

SOAP इंटरनेट पर संदेश, या थोड़ी मात्रा में जानकारी स्थानांतरित करने की एक विधि है। SOAP संदेशों को XML में स्वरूपित किया जाता है और आमतौर पर HTTP (हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल) का उपयोग करके भेजा जाता है।

---

बाकी - प्रतिनिधि राज्य हस्तांतरण

बाकी क्लाइंट और सर्वर के बीच डेटा भेजने और प्राप्त करने का एक सरल तरीका है और इसमें बहुत सारे मानक परिभाषित नहीं हैं। आप JSON, XML या यहां तक ​​कि सादे पाठ के रूप में डेटा भेज और प्राप्त कर सकते हैं। यह SOAP की तुलना में हल्का है।

---

Comments

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

— एल्मूर्ते

SOAP HTTP या XML का उपयोग करने के लिए NO WAY बल में करता है। HTTP और XML, अंतर-प्रयोज्यता के लिए WS-I में परिभाषित चीजें हैं, लेकिन कोई JJ पर POJO भी भेज सकता है। बात यह है, कि प्रोग्रामर को देखभाल करने की आवश्यकता नहीं है: सेवा बस परिवहन और एन्कोडिंग का प्रबंधन करती है।

— koppor

प्रत्येक जटिल समस्या के लिए एक उत्तर है जो स्पष्ट, सरल और गलत है। --HL Mencken

— JMH

उदाहरण महाकाव्य था!

— केदुल

पढ़ते रहिये। जबकि यह उत्तर मनोरंजक है @ पावेल का उत्तर नीचे अधिक पूर्ण है।

— जोश जॉनसन

Answer 2

दोनों तरीकों का उपयोग कई बड़े खिलाड़ियों द्वारा किया जाता है। यह वरीयता की बात है। मेरी प्राथमिकता REST है क्योंकि इसका उपयोग करना और समझना सरल है।

सरल ऑब्जेक्ट एक्सेस प्रोटोकॉल (SOAP):

• SOAP HTTP या कभी-कभी टीसीपी / आईपी के ऊपर एक XML प्रोटोकॉल बनाता है।
• SOAP फ़ंक्शन और डेटा के प्रकारों का वर्णन करता है।
• SOAP XML-RPC का उत्तराधिकारी है और बहुत समान है, लेकिन संवाद करने के लिए एक मानक तरीका बताता है।
• कई प्रोग्रामिंग भाषाओं में SOAP के लिए मूल समर्थन है, आप आमतौर पर इसे एक वेब सेवा URL खिलाते हैं और आप विशिष्ट कोड की आवश्यकता के बिना इसके वेब सेवा कार्यों को कॉल कर सकते हैं।
• भेजे गए बाइनरी डेटा को पहले बेस 64 एनकोडेड जैसे प्रारूप में एन्कोड किया जाना चाहिए।
• WSDL, XSDs, सोप, WS- एड्रेसिंग से संबंधित कई प्रोटोकॉल और प्रौद्योगिकियां हैं

प्रतिनिधि राज्य स्थानांतरण (REST):

• REST को HTTP पर नहीं होना चाहिए, लेकिन नीचे दिए गए मेरे अधिकांश बिंदुओं में HTTP पूर्वाग्रह होगा।
• REST बहुत हल्का है, यह कहता है कि एक मिनट रुको, हमें इस जटिलता की आवश्यकता नहीं है जो SOAP ने बनाई है।
• आमतौर पर सब कुछ का वर्णन करने वाले एक बड़े XML प्रारूप के बजाय सामान्य HTTP तरीकों का उपयोग करता है। एक संसाधन प्राप्त करने के लिए उदाहरण के लिए आप HTTP GET का उपयोग करते हैं, HTTP PUT का उपयोग करने वाले सर्वर पर एक संसाधन लगाने के लिए। सर्वर पर एक संसाधन को हटाने के लिए आप HTTP DELETE का उपयोग करते हैं।
• REST एक बहुत ही सरल है जिसमें यह सर्वर पर संसाधनों को अपडेट करने के लिए HTTP GET, POST और PUT विधियों का उपयोग करता है।
• REST आमतौर पर रिसोर्स ओरिएंटेड आर्किटेक्चर (ROA) के साथ सबसे अच्छा उपयोग किया जाता है । सोचने की इस विधा में सब कुछ एक संसाधन है, और आप इन संसाधनों पर काम करेंगे।
• जब तक आपकी प्रोग्रामिंग लैंग्वेज में एक HTTP लाइब्रेरी है, और सबसे अधिक, आप बहुत आसानी से REST HTTP प्रोटोकॉल का उपभोग कर सकते हैं।
• बाइनरी डेटा या बाइनरी संसाधनों को केवल उनके अनुरोध पर वितरित किया जा सकता है।

Google पर REST vs SOAP पर अंतहीन बहसें हैं ।

मेरा पसंदीदा इस एक है । 27 नवंबर 2013 को अपडेट करें: पॉल प्रेस्कॉड की साइट ऑफ़लाइन हो गई है और यह लेख अब उपलब्ध नहीं है, प्रतियां हालांकि वेबैक मशीन या CiteSeerX में पीडीएफ के रूप में पाई जा सकती हैं ।

Comments

REST का HTTP (यह प्रोटोकॉल स्वतंत्र है) से कोई लेना-देना नहीं है, और XML एक RESTful वास्तुकला के भीतर उपयोग करने के लिए ठीक है। GET / POST / PUT / DELETE केवल HTTP का सही उपयोग कर रहा है - REST के लिए आवश्यक है लेकिन पर्याप्त नहीं है।

— aehlke

REST क्लाइंट कैसे जान सकता है कि वह किन तरीकों और प्रकारों का उपयोग कर सकता है? SOAP में WSDL है जहाँ से कई उपकरण कक्षाएं और विधियाँ उत्पन्न कर सकते हैं।

— jlp

@jlp: यह REST क्लाइंट डेवलपर पर निर्भर है कि वह उजागर REST इंटरफेस का सही इस्तेमाल करे।

— ब्रायन आर। बॉन्डी

REST बस कहता है कि 'एक समान इंटरफ़ेस का उपयोग करें'। चूंकि HTTP इंटरफ़ेस [GET, POST, PUT, DELETE, (UPDATE, HEAD)] वेब का 'एकसमान इंटरफ़ेस' बन गया है, REST (वेब ​​पर) किसी तरह मेरी राय में HTTP पर निर्भर है!

— आंद्रे श्वेघोफर

@aehlke REST HTTP पर बहुत निर्भर है। अन्यथा कहना पागल है। REST दृष्टिकोण HTTP RFC (W3C TAG द्वारा) को ठोस रूप से परिभाषित किया गया है। यूसी इरविन के रॉय फील्डिंग द्वारा डॉक्टरेट शोध प्रबंध के अलावा इसका कोई अन्य विनिर्देश नहीं है। देखें: en.wikipedia.org/wiki/Representational_state_transfer

— ब्रेंडेन

Answer 3

आराम

मैं समझता हूं कि REST का मुख्य विचार अत्यंत सरल है। हमने वर्षों से वेब ब्राउज़र का उपयोग किया है और हमने देखा है कि वेब साइट्स कितनी आसान, लचीली, प्रदर्शनकारी आदि हैं। HTML साइटें उपयोगकर्ता के इंटरैक्शन के प्राथमिक साधनों के रूप में हाइपरलिंक और फॉर्म का उपयोग करती हैं। उनका मुख्य लक्ष्य हमें ग्राहकों, केवल उन लिंक को जानना है, जिन्हें हम वर्तमान स्थिति में उपयोग कर सकते हैं । और REST बस कहता है कि 'हमारे एप्लिकेशन के माध्यम से मानव क्लाइंट के बजाय कंप्यूटर को चलाने के लिए समान सिद्धांतों का उपयोग क्यों न करें?' इसे डब्ल्यूडब्ल्यूडब्ल्यू बुनियादी ढांचे की शक्ति के साथ मिलाएं और आपको महान वितरित अनुप्रयोगों के निर्माण के लिए हत्यारा उपकरण मिलेगा।

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

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

दुर्भाग्य से, रॉय फील्डिंग की थीसिस को छोड़कर, वेब पर REST की सही जानकारी प्राप्त करना कठिन है । (वह वही है जो बाकी प्राप्त किया है)। मैं सिफारिश करूंगा 'रीस्ट इन प्रैक्टिस' पुस्तक क्योंकि यह SOAP से REST तक विकसित होने के बारे में एक व्यापक चरण-दर-चरण ट्यूटोरियल देता है।

साबुन

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

तुलना

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

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

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

अपडेट करें

मेरे अनुभव ने अप्रत्याशित रूप से RAP विकास को SOAP से अधिक कठिन बना दिया है। कम से कम .NET के लिए। हालांकि ASP.NET वेब एपीआई जैसी महान रूपरेखाएं हैं, कोई भी टूलिंग नहीं है जो स्वचालित रूप से क्लाइंट-साइड प्रॉक्सी उत्पन्न करेगा। 'वेब सेवा संदर्भ जोड़ें' या 'WCF सेवा संदर्भ जोड़ें' जैसा कुछ नहीं। एक को हाथ से सभी क्रमांकन और सेवा क्वेरी कोड लिखना होगा। और आदमी, यह बहुत सारे बॉयलरप्लेट कोड है। मुझे लगता है कि REST विकास को प्रत्येक विकास मंच के लिए WSDL और टूलिंग कार्यान्वयन के समान कुछ चाहिए। वास्तव में, एक अच्छा आधार प्रतीत होता है: WADL या WSDL 2.0 , लेकिन दोनों में से कोई भी मानक अच्छी तरह से समर्थित नहीं है।

अपडेट (जनवरी 2016)

अब पता चलता है कि REST API परिभाषा के लिए कई प्रकार के उपकरण हैं । वर्तमान में मेरी व्यक्तिगत प्राथमिकता RAML है ।

वेब सेवा कैसे काम करती है

खैर, यह एक बहुत व्यापक प्रश्न है, क्योंकि यह विशिष्ट वेब सेवा में उपयोग की जाने वाली वास्तुकला और प्रौद्योगिकी पर निर्भर करता है। लेकिन सामान्य तौर पर, एक वेब सेवा वेब में बस कुछ अनुप्रयोग है जो ग्राहकों से अनुरोध स्वीकार कर सकते हैं और प्रतिक्रियाएं दे सकते हैं। यह वेब के संपर्क में है, इस प्रकार यह एक वेब सेवा है, और यह आमतौर पर 24/7 उपलब्ध है, इसीलिए यह एक सेवा है । बेशक, यह कुछ समस्या को हल करता है (अन्यथा कोई अपने ग्राहकों के लिए किसी वेब सेवा का उपयोग क्यों करेगा)।

Comments

यह अब तक का सबसे उत्कीर्ण उत्तर होना चाहिए! मेरे पास हास्य की भावना है, लेकिन यह निराशाजनक है जब स्टैकऑवरफ्लो ट्रम्प पर कॉमेडी का जवाब अच्छी तरह से माना जाता है।

— टॉम डब्ल्यू हॉल

@TomHall मुझे लगता है कि यह स्थिति REST - RPC चर्चा के लिए विशिष्ट है, न कि केवल SO पर। मुझे लगता है कि यही कारण है कि हमारे पास REST ग्राहकों के लिए उचित टूलींग नहीं है। कम से कम .NET पर, REST सेवा क्लाइंट को लागू करना SOAP सेवा संदर्भ उत्पन्न करने की तुलना में अधिक कठिन साबित हुआ है। एक को प्रॉक्सी कक्षाओं को हाथ से लिखना होगा। किसी कारण से लोग REST के बारे में सोचते हैं जैसे कि कोई नियम नहीं थे, जबकि इसके विपरीत मूल विचार वास्तुकला पर बहुत अधिक प्रतिबंध लगाता है। मेरी इच्छा है कि समुदाय REST को समझे - तब हम बेहतर टूलींग और गोद लेने की उम्मीद कर सकते हैं।

— पावेल गातिलोव

@PavelGatilov यह उत्तर बहुत अच्छा है। मैंने अन्य आरईएस स्पष्टीकरण पढ़ा था और कभी भी "यह नहीं मिला" कि ड्राइविंग सिद्धांत यह है कि संभव राज्य संक्रमण प्रतिक्रिया का हिस्सा है। तथ्य यह है कि आपने अपने अनुभव को वापस प्रतिबिंबित करने और कठिनाइयों को स्वीकार करने के लिए समय लिया, हम सभी के लिए भी बहुत महत्व है।

बहुत बढ़िया जवाब। मुझे आश्चर्य है कि REST-I को कितना समय लगेगा, अब इसके साथ विकसित होने के लिए अधिक से अधिक SOAP दिखना शुरू हो जाएगा जैसे RAML, स्वैगर और WADL इसे REST होने के de-facto मानक के लिए निर्धारित करते हैं। मैंने SOAP की तुलना में REST पर टूलींग की कमी को पाया, जब कुछ संवेदनशील और जटिल वित्तीय प्रणालियों को विकसित करते हुए एक प्रमुख दर्द। सही तरीके से इस्तेमाल करने पर REST और SOAP दोनों कमाल के हैं। मेरे दादाजी ने हमेशा कहा कि आप एक नाखून में हथौड़ा करने के लिए एक पेचकश का उपयोग कर सकते हैं लेकिन यह अच्छी तरह से काम करने वाला नहीं है। वही यहाँ लागू होता है। नौकरी मानसिकता के लिए सही उपकरण नहीं मेरे रास्ते एक ही रास्ता है \।

— Namphibian

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

— नामीबिया

Answer 4

यह सबसे सरल स्पष्टीकरण है जो आप कभी भी पाएंगे।

यह लेख एक पति को पत्नी की कथा में ले जाता है, जहाँ पति अपनी पत्नी को शुद्ध आम शब्दों में REST के बारे में समझाता है। जरूर पढ़े!

How-i-समझाया-बाकी-से-मेरी पत्नी (मूल लिंक)
how-i-समझाया-बाकी-से-मेरी पत्नी (2013-07-19 कामकाजी लिंक)

Comments

बहुरूपता के बारे में हिस्सा सुंदर है।

— प्रोफैट्स

Answer 5

SOAP - सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल एक प्रोटोकॉल है !

बाकी - प्रतीकात्मक राज्य स्थानांतरण एक स्थापत्य शैली है !

SOAP एक XML प्रोटोकॉल है जो आमतौर पर HTTP पर संदेशों को स्थानांतरित करने के लिए उपयोग किया जाता है

RESTऔर यकीनन परस्पर अनन्य नहींSOAP हैं । एक आरामदायक वास्तुकला का उपयोग कर सकते या या कुछ अन्य संचार प्रोटोकॉल। वेब के लिए अनुकूलित है और इस प्रकार एक आदर्श विकल्प है। रॉय फील्डिंग के पेपर में चर्चा करने वाला एकमात्र प्रोटोकॉल भी है । HTTPSOAPRESTHTTPHTTP

हालाँकि REST और SOAP स्पष्ट रूप से बहुत अलग हैं, लेकिन यह प्रश्न इस तथ्य पर रोशनी डालता है कि RESTऔरHTTP इसका उपयोग अक्सर किया जाता है। यह मुख्य रूप से HTTP की सादगी और Restful सिद्धांतों के लिए बहुत ही प्राकृतिक मानचित्रण के कारण है।

मौलिक अनुष्ठान सिद्धांत

क्लाइंट-सर्वर संचार

क्लाइंट-सर्वर आर्किटेक्चर के पास चिंताओं का एक अलग अलगाव है। रैस्टफुल स्टाइल में निर्मित सभी एप्लिकेशन को प्रिंसिपल में क्लाइंट-सर्वर भी होना चाहिए।

राज्यविहीन

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

संचित करने योग्य

कैश की कमी का उपयोग किया जा सकता है, इस प्रकार प्रतिक्रिया डेटा को कैचीबल या नहीं-केचबल के रूप में चिह्नित किया जा सकता है। कैचवेबल के रूप में चिह्नित किसी भी डेटा को उसी बाद के अनुरोध की प्रतिक्रिया के रूप में पुन: उपयोग किया जा सकता है।

यूनिफ़ॉर्म इंटरफ़ेस

सभी घटकों को एक समान वर्दी इंटरफेस के माध्यम से बातचीत करनी चाहिए। क्योंकि इस इंटरफ़ेस के माध्यम से सभी घटक इंटरैक्शन होते हैं, विभिन्न सेवाओं के साथ बातचीत बहुत सरल है। इंटरफ़ेस एक ही है! इसका अर्थ यह भी है कि अलगाव में कार्यान्वयन परिवर्तन किए जा सकते हैं। इस तरह के परिवर्तन, मौलिक घटक इंटरैक्शन को प्रभावित नहीं करेंगे क्योंकि वर्दी इंटरफ़ेस हमेशा अपरिवर्तित रहता है। एक नुकसान यह है कि आप इंटरफ़ेस के साथ फंस गए हैं। यदि इंटरफ़ेस बदलकर एक विशिष्ट सेवा के लिए एक अनुकूलन प्रदान किया जा सकता है, तो आप भाग्य से बाहर हैं क्योंकि REST इसे प्रतिबंधित करता है। उज्ज्वल पक्ष पर, हालांकि, REST वेब के लिए अनुकूलित है, इसलिए HTTP पर REST की अविश्वसनीय लोकप्रियता है!

उपरोक्त अवधारणाएं आरईएसटी की परिभाषित विशेषताओं का प्रतिनिधित्व करती हैं और अन्य आर्किटेक्चर जैसे वेब सेवाओं से अन्य आर्किटेक्चर को अलग करती हैं। यह ध्यान रखना उपयोगी है कि REST सेवा एक वेब सेवा है, लेकिन एक वेब सेवा आवश्यक रूप से REST सेवा नहीं है।

REST और ऊपर बताई गई गोलियों के बारे में अधिक जानकारी के लिए REST डिज़ाइन प्रिंसिपलों पर इस ब्लॉग पोस्ट को देखें ।

Comments

केवल यह सोचना कि किसी RESTful संसाधन का अनुरोध करने के लिए पूरी तरह से HATEOAS होगा और एक प्रतिक्रिया प्राप्त करेगा जिसमें WSDL के लिए एक लिंक शामिल है जिसमें यह वर्णन किया गया है कि वर्तमान स्थिति में उस संसाधन पर कौन से ऑपरेशन उपलब्ध हैं। हालांकि मुझे लगता है कि एक RESTful SOAP वेब सेवा RMM स्तर 3 पर लंघन करने और सीधे स्तर 4 पर जाने की तरह होगी। :)

— स्टीव

यह प्रतिबिंबित करने के लिए सबसे अच्छा जवाब है कि यह या तो नहीं है या REST और SOAP के साथ नहीं है। +1 ध्यान दें कि REST एक शैली है ।

— ABMagil

Answer 6

मुझे ब्रायन आर बॉडी का जवाब पसंद है। मैं सिर्फ यह जोड़ना चाहता था कि विकिपीडिया REST का स्पष्ट विवरण प्रदान करता है । लेख इसे SOAP से अलग करता है।

REST राज्य सूचनाओं का एक आदान-प्रदान है, बस यथाशीघ्र किया जाता है।

SOAP एक संदेश प्रोटोकॉल है जो XML का उपयोग करता है।

कई लोगों ने SOAP से REST में जाने के मुख्य कारणों में से एक यह है कि SOAP आधारित वेब सेवाओं के साथ जुड़े WS- * (WS splat) मानक अत्यधिक जटिल हैं। विनिर्देशों की सूची के लिए विकिपीडिया देखें । इनमें से प्रत्येक विनिर्देश बहुत जटिल है।

संपादित करें: किसी कारण से लिंक सही ढंग से प्रदर्शित नहीं हो रहे हैं। REST = http://en.wikipedia.org/wiki/REST

WS- * = http://en.wikipedia.org/wiki/WS- *

Comments

सोप एक प्रोटोकॉल नहीं है। SOAP एन्कोडिंग के बारे में है। SOAP का प्रयोग कई प्रोटोकॉलों पर किया जाता है: JMS, http, ...

— कोपर

@koppor आप का अर्थ है कि यह "सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल" के लिए है? इसके अलावा, क्या आप जानते हैं कि एक प्रोटोकॉल क्या है? एक प्रोटोकॉल मूल रूप से नियमों का एक सेट है कि दो या दो से अधिक चीजों को कैसे संवाद करना चाहिए, जो कि वास्तव में SOAP है, जो एक मानक तरीका है।

— 22

@Demizey क्या आप SOAP के सबसे हाल के संस्करण का संदर्भ देते हैं, जो 1.2 है? w3.org/TR/soap12-part1 "SOAP" अब अपने आप में खड़ा है क्योंकि व्यवहार में इसे प्रोटोकॉल के रूप में उपयोग नहीं किया जाता है। "एसओएपी 1.2 परिचित नहीं होगा।" ( w3.org/TR/2007/REC-soap12-part0-20070427/#L4697 ) क्या आप वेब सर्विस स्टैक की परतों से अवगत हैं (जैसे) पुस्तक "वेब सर्विसेज प्लेटफॉर्म आर्किटेक्चर: साबुन, डब्ल्यूएसडीएल, डब्ल्यूएस में वर्णित है। -पुलिस, डब्ल्यूएस-एड्रेसिंग, डब्ल्यूएस-बीपीएल, डब्ल्यूएस-विश्वसनीय संदेश और अधिक "? ट्रांसपोर्ट-लेयर कम्युनिकेशन HTTP, SMTP, RMI / IIOP, JMS या अन्य के माध्यम से किया जाता है। SOAP का उपयोग मैसेजिंग लेयर में किया जाता है

— koppor

SOAP कनेक्शन की लाइन के साथ, कई बिचौलिए बैठ सकते हैं। यह SOAP प्रोसेसिंग मॉडल द्वारा सक्षम है, जो कि अंतिम SOAP रिसीवर और शून्य या अधिक SOAP बिचौलियों के बीच प्रतिष्ठित है। ट्रांसपोर्ट प्रोटोकॉल इनबेटन बदल सकता है। SOAP संदेश पथ ईएआई पैटर्न ( eaipatterns.com ) के पारदर्शी कार्यान्वयन में सक्षम बनाता है

— koppor

यह अभी भी एक मैसेजिंग प्रोटोकॉल है।

— केयर्स

Answer 7

SOAP वेबसर्विस और REST वेबसर्विस दोनों HTTP प्रोटोकॉल और अन्य प्रोटोकॉल का उपयोग कर सकते हैं (बस SOAP का उल्लेख करने के लिए REST के अंतर्निहित प्रोटोकॉल हो सकते हैं)। मैं केवल HTTP प्रोटोकॉल से संबंधित SOAP और REST के बारे में बात करूंगा, क्योंकि यह उनका सबसे अधिक उपयोग है।

साबुन

SOAP ("सरल" ऑब्जेक्ट एक्सेस प्रोटोकॉल) एक प्रोटोकॉल (और एक W3C मानक ) है। यह SOAP संदेशों को बनाने, भेजने और संसाधित करने का तरीका निर्धारित करता है।

• SOAP संदेश एक विशिष्ट संरचना के साथ XML दस्तावेज़ हैं: इनमें एक लिफाफा होता है जिसमें हेडर और बॉडी सेक्शन होता है। शरीर में वास्तविक डेटा होता है - हम एक XML प्रारूप में भेजना चाहते हैं। कर रहे हैं दो एन्कोडिंग शैलियों , लेकिन हम आम तौर पर शाब्दिक चुनें , जिसका अर्थ है कि हमारे आवेदन या उसके सोप ड्राइवर एक्सएमएल क्रमबद्धता और डेटा की unserialization करता है।

• SOAP + XML MIME उपप्रकार के साथ SOAP संदेश HTTP संदेश के रूप में यात्रा करते हैं। ये HTTP संदेश मल्टीपार्ट हो सकते हैं, इसलिए वैकल्पिक रूप से हम SOAP संदेशों में फ़ाइलें संलग्न कर सकते हैं।

• स्पष्ट रूप से हम एक क्लाइंट-सर्वर आर्किटेक्चर का उपयोग करते हैं, इसलिए एसओएपी क्लाइंट एसओएपी वेबसीरीज के लिए अनुरोध भेजते हैं और सेवाएं ग्राहकों को प्रतिक्रियाएं भेजती हैं। अधिकांश वेबसर्विसेस सेवा का वर्णन करने के लिए एक WSDL फ़ाइल का उपयोग करते हैं। WSDL फ़ाइल में XML स्कीमा (XSD उसके बाद) जो हम भेजना चाहते हैं और WSDL बाइंडिंग है जो परिभाषित करता है कि कैसे webservice HTTP प्रोटोकॉल के लिए बाध्य है। वहां दो बाध्यकारी शैलियों: RPC और दस्तावेज़। RPC शैली बाइंडिंग SOAP बॉडी में पैरामीटर (HTTP अनुरोध) या रिटर्न वैल्यूज़ (HTTP रिस्पांस) के साथ एक ऑपरेशन कॉल का प्रतिनिधित्व होता है। पैरामीटर और रिटर्न मान XSD के खिलाफ मान्य हैं। दस्तावेज़ शैली द्वारा SOAP बॉडी को बाइंड करने पर XML दस्तावेज़ होता है जो XSD के विरुद्ध मान्य होता है। मुझे लगता है कि दस्तावेज़ बाध्यकारी शैली घटना आधारित प्रणालियों के लिए बेहतर है, लेकिन मैंने कभी भी उस बाध्यकारी शैली का उपयोग नहीं किया। RPC बाइंडिंग शैली अधिक प्रचलित है, इसलिए अधिकांश लोग वितरित अनुप्रयोगों द्वारा XML / RPC उद्देश्यों के लिए SOAP का उपयोग करते हैं। यूडीडीआई सर्वर आमतौर पर यूडीडीआई सर्वर से पूछकर एक दूसरे को खोजते हैं। UDDI सर्वर रजिस्ट्रियां हैं जो वेबसर्विस के स्थान को स्टोर करती हैं।

SOAP आरपीसी

तो - मेरी राय में - सबसे प्रचलित SOAP वेब सेवा RPC बाइंडिंग शैली और शाब्दिक एन्कोडिंग शैली का उपयोग करती है और इसमें निम्नलिखित विशेषताएं हैं:

• यह संचालन के लिए URL मैप करता है।
• यह SOAP + XML MIME उपप्रकार के साथ संदेश भेजता है।
• इसमें सर्वर साइड सेशन स्टोर हो सकता है, इस बारे में कोई अड़चन नहीं है।
• SOAP क्लाइंट ड्राइवर RPC ऑपरेशन को विधियों में बदलने के लिए सेवा की WSDL फ़ाइल का उपयोग करते हैं। क्लाइंट साइड एप्लिकेशन इन विधियों को कॉल करके SOAP वेब सेवा के साथ संचार करता है। इसलिए SOAP के अधिकांश ग्राहक इंटरफ़ेस परिवर्तन (परिणामस्वरूप विधि नाम और / या पैरामीटर परिवर्तन) से टूट जाते हैं।
• SOAP क्लाइंट लिखना संभव है जो RDF का उपयोग करके इंटरफ़ेस परिवर्तन से नहीं टूटेगा और शब्दार्थ द्वारा संचालन ढूंढेगा, लेकिन शब्दार्थ वेबबेस बहुत दुर्लभ हैं और उनके पास आवश्यक रूप से एक गैर ब्रेकिंग क्लाइंट नहीं है (मुझे लगता है)।

आराम

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

बाकी बाधाएं

• क्लाइंट - सर्वर आर्किटेक्चर - मुझे लगता है कि यह हिस्सा सभी के लिए परिचित है। REST ग्राहक REST वेबसर्विसेस के साथ संवाद करते हैं, webservices आम डेटा - संसाधन स्थिति को उसके बाद बनाए रखता है - और इसे ग्राहकों को प्रदान करता है।
• स्टेटलेस - संक्षिप्त नाम का "राज्य स्थानांतरण" भाग: REST। क्लाइंट क्लाइंट स्थिति (सत्र / अनुप्रयोग स्थिति) को बनाए रखते हैं, इसलिए सेवाओं में सत्र संग्रहण नहीं होना चाहिए। क्लाइंट क्लाइंट राज्य के संबंधित अनुरोध को उन सेवाओं के लिए स्थानांतरित करते हैं जो संसाधन राज्य के प्रासंगिक हिस्से (उनके द्वारा बनाए रखा गया) के साथ प्रतिक्रिया करते हैं। इसलिए अनुरोधों का संदर्भ नहीं है, उन्हें संसाधित करने के लिए हमेशा आवश्यक जानकारी होती है। उदाहरण के लिए HTTP बेसिक नॉर्म के द्वारा यूजरनेम और पासवर्ड क्लाइंट द्वारा स्टोर किया जाता है, और यह उन्हें हर रिक्वेस्ट के साथ भेजता है, इसलिए ऑथेंटिकेशन हर रिक्वेस्ट से होता है। यह नियमित वेबपेजों से बहुत अलग है जहां प्रमाणीकरण केवल लॉगिन से होता है। हम इन-मेमोरी (जावास्क्रिप्ट), कुकीज, लोकलस्टोरेज जैसे किसी भी क्लाइंट साइड डेटा स्टोरेज मैकेनिज्म का उपयोग कर सकते हैं ... अगर हम चाहें तो क्लाइंट स्टेट के कुछ हिस्सों को जारी रख सकते हैं। स्टेटलेसनेस की कमी का कारण, कि सर्वर बहुत अच्छी तरह से लोड होता है - यहां तक ​​कि बहुत अधिक लोड (लाखों उपयोगकर्ता) द्वारा - जब इसे हर एक क्लाइंट के सत्र को बनाए रखने की आवश्यकता नहीं होती है।
• कैश - प्रतिक्रिया में ग्राहक के द्वारा कैश किया जा सकता है या नहीं, इसके बारे में जानकारी होनी चाहिए। यह स्केलेबिलिटी को और बेहतर बनाता है।

• यूनिफ़ॉर्म इंटरफ़ेस

  • संसाधनों की पहचान - REST संसाधन RDF संसाधन के समान है । क्षेत्ररक्षण के अनुसार यदि आप कुछ नाम दे सकते हैं, तो यह एक संसाधन हो सकता है, उदाहरण के लिए: "वर्तमान स्थानीय मौसम" एक संसाधन हो सकता है, या "आपका मोबाइल फोन" एक संसाधन हो सकता है, या "एक विशिष्ट वेब दस्तावेज़" हो सकता है संसाधन। संसाधन की पहचान करने के लिए आप संसाधन पहचानकर्ताओं का उपयोग कर सकते हैं: यूआरएल और यूआरएन (उदाहरण के लिए किताबों द्वारा आईएसबीएन संख्या )। एक एकल पहचानकर्ता केवल एक विशिष्ट संसाधन से संबंधित होना चाहिए, लेकिन एक एकल संसाधन में कई पहचानकर्ता हो सकते हैं, जिनका हम अक्सर URL जैसे पेजेशन द्वारा उदाहरण के लिए शोषण करते हैं https://example.com/api/v1/users?offset=50&count=25। URL में कुछ विनिर्देश हैं, उदाहरण के लिए एक ही पथ वाले URL, लेकिन अलग-अलग क्वेरीज़ समान नहीं हैं, या पथ भाग में URL का श्रेणीबद्ध डेटा होना चाहिए और क्वेरी भाग में गैर-श्रेणीबद्ध डेटा होना चाहिए। REST द्वारा URL कैसे बनाया जाए, ये मूल बातें हैं। Btw। URL संरचना केवल सेवा डेवलपर्स के लिए ही मायने रखती है, एक वास्तविक REST क्लाइंट इसके साथ चिंता नहीं करता है। एक और अक्सर पूछा जाने वाला प्रश्न एपीआई संस्करण है, जो एक आसान है, क्योंकि क्षेत्ररक्षण के अनुसार संसाधन द्वारा एकमात्र स्थिर चीज शब्दार्थ है। यदि शब्दार्थ बदल जाता है, तो आप एक नया संस्करण संख्या जोड़ सकते हैं। आप शास्त्रीय 3 नंबर संस्करण का उपयोग कर सकते हैं और URL में केवल प्रमुख संख्या जोड़ सकते हैं (https://example.com/api/v1/)। इसलिए पिछड़े संगत परिवर्तनों से कुछ नहीं होता है, गैर-पिछड़े संगत परिवर्तनों के द्वारा आपके पास एक नया एपीआई रूट के साथ एक गैर-पिछड़े संगत शब्दार्थ होगा https://example.com/api/v2/। इसलिए पुराने ग्राहक टूटेंगे नहीं, क्योंकि वे https://example.com/api/v1/पुराने शब्दार्थ के साथ प्रयोग कर सकते हैं ।
  • अभ्यावेदन के माध्यम से संसाधनों का हेरफेर - आप संसाधनों का संबंधित प्रतिनिधित्व (HTTP स्थिति) से संबंधित डेटा को हेरफेर कर सकते हैं - HTTP विधि और संसाधन पहचानकर्ता के साथ - REST सेवा के लिए। उदाहरण के लिए यदि आप शादी के बाद किसी उपयोगकर्ता का नाम बदलना चाहते हैं, तो आप एक PATCH https://example.com/api/v1/users/1 {name: "Mrs Smith"}अनुरोध भेज सकते हैं, जहां {name: "Mrs Smith"}दूसरे संसाधन में JSON प्रतिनिधित्व है, दूसरे शब्दों में: नया नाम। यह विकी-वर्सा होता है, सेवा अपने राज्यों को बदलने के लिए ग्राहकों को संसाधनों का प्रतिनिधित्व भेजती है। उदाहरण के लिए यदि हम नया नाम पढ़ना चाहते हैं, तो हम एक GET https://example.com/api/v1/users/1?fields="name"रिट्रीवल अनुरोध भेज सकते हैं, जिसके परिणामस्वरूप ए200 ok, {name: "Mrs Smith"}प्रतिक्रिया। इसलिए हम ग्राहक की स्थिति को बदलने के लिए इस प्रतिनिधित्व का उपयोग कर सकते हैं, उदाहरण के लिए हम "हमारे पृष्ठ पर आपका स्वागत है श्रीमती स्मिथ!" संदेश। संसाधन के पास रिसोर्स आइडेंटिफ़ायर (URL) या acceptअनुरोध के साथ भेजे गए हेडर के आधार पर कई अभ्यावेदन हो सकते हैं । उदाहरण के लिए, यदि image/jpegअनुरोध किया जाए तो हम श्रीमती स्मिथ की छवि भेज सकते हैं (शायद नग्न नहीं) ।
  • स्व-वर्णनात्मक संदेश - संदेशों में उन्हें संसाधित करने के तरीके के बारे में जानकारी होनी चाहिए। उदाहरण के लिए यूआरआई और एचटीटीपी विधि, कंटेंट टाइप हेडर, कैश हेडर, आरडीएफ जो डेटा का अर्थ बताता है, आदि ... मानक विधियों का उपयोग करना महत्वपूर्ण है। HTTP विधियों के विनिर्देश को जानना महत्वपूर्ण है । उदाहरण के लिए, GET का अर्थ है अनुरोध URL द्वारा पहचानी गई जानकारी को पुनः प्राप्त करना, DELETE का अर्थ है सर्वर को दिए गए URL द्वारा पहचाने गए संसाधन को हटाने के लिए कहना, और इसी तरह ... HTTP स्थिति कोड में एक विनिर्देशन है , उदाहरण के लिए 200 का अर्थ है सफलता, 201 का अर्थ है एक नया संसाधन बनाया गया है, 404 का अर्थ है कि अनुरोधित संसाधन सर्वर पर नहीं मिला, आदि ... मौजूदा मानकों का उपयोग करना REST का एक महत्वपूर्ण हिस्सा है।

  • हाइपरमीडिया अनुप्रयोग राज्य के इंजन के रूप में (उसके बाद) - हाइपरमीडिया एक मीडिया प्रकार है जिसमें हाइपरलिंक हो सकते हैं। वेब द्वारा हम एक लक्ष्य को प्राप्त करने के लिए हाइपरमीडिया प्रारूप (आमतौर पर HTML) द्वारा वर्णित लिंक का अनुसरण करते हैं - URL को एडरेस बार में टाइप करने के बजाय, एक लक्ष्य प्राप्त करने के लिए। REST समान अवधारणा का अनुसरण करता है, सेवा द्वारा भेजे गए अभ्यावेदन में हाइपरलिंक हो सकते हैं। हम सेवा में अनुरोध भेजने के लिए इन हाइपरलिंक्स का उपयोग करते हैं। प्रतिक्रिया के साथ हमें डेटा (और शायद अधिक लिंक) मिलते हैं, जिसका उपयोग हम नए क्लाइंट राज्य के निर्माण के लिए कर सकते हैं, और इसी तरह ... इसलिए हाइपरमीडिया एप्लीकेशन स्टेट (क्लाइंट स्टेट) का इंजन है। आप शायद आश्चर्य करते हैं कि क्लाइंट हाइपरलिंक को कैसे पहचानते हैं और उसका पालन करते हैं? मनुष्यों द्वारा यह बहुत सरल है, हम लिंक का शीर्षक पढ़ते हैं, शायद इनपुट फ़ील्ड भरें, और उसके बाद बस एक क्लिक करें।JSON-LD हाइड्रा के साथ ) या हाइपरमीडिया विशिष्ट समाधानों के साथ (उदाहरण के लिए IANA लिंक संबंध और HAL + JSON द्वारा विशिष्ट MIME प्रकार )। कई मशीन पठनीय XML और JSON हाइपरमीडिया प्रारूप हैं , बस उनकी एक छोटी सूची है:

    • एक्सएचटीएमएल
    • एटम + एक्सएमएल
    • RDF + एक्सएमएल
    • एचएएल + एक्सएमएल
    • एचएएल + JSON
    • JSON-LD
    • RDF + JSON
    • भोंपू
    • संग्रह + JSON

    कभी-कभी चुनना मुश्किल होता है ...

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

बाकी webservice - सोप आरपीसी webservice मतभेद

इसलिए REST webservice एक SOAP webservice (RPC बाइंडिंग स्टाइल और शाब्दिक एन्कोडिंग शैली के साथ) से बहुत अलग है

• यह एक समान इंटरफ़ेस (एक प्रोटोकॉल का अंतर) को परिभाषित करता है।
• यह संसाधनों (और संचालन नहीं) के लिए URL को मैप करता है।
• यह किसी भी MIME प्रकार (सिर्फ SOAP + XML के बजाय) के साथ संदेश भेजता है।
• इसमें एक स्टेटलेस संचार होता है, और इसलिए इसमें सर्वर साइड सेशन स्टोरेज नहीं हो सकता है। (SOAP को इस बारे में कोई अड़चन नहीं है)
• यह हाइपरमीडिया की सेवा करता है और ग्राहक सेवा का अनुरोध करने के लिए उस हाइपरमीडिया द्वारा निहित लिंक का उपयोग करते हैं। (SOAP RPC WSDL फ़ाइल में वर्णित ऑपरेशन बाइंडिंग का उपयोग करता है)
• यह केवल शब्दार्थ परिवर्तन द्वारा URL परिवर्तनों से नहीं टूटता है। (WSDL फ़ाइल परिवर्तनों द्वारा RDF शब्दार्थ विराम का उपयोग किए बिना SOAP RPC क्लाइंट।)
• यह एक एसएएपी वेब सेवा की तुलना में बेहतर है क्योंकि यह अपने स्टेटलेस व्यवहार के कारण है।

और इसी तरह...

एक SOAP RPC वेबसर्स्ट बाकी सभी बाधाओं को पूरा नहीं करता है:

• क्लाइंट-सर्वर आर्किटेक्चर - हमेशा
• स्टेटलेस - संभव
• कैश - संभव
• वर्दी इंटरफ़ेस - कभी नहीं
• स्तरित प्रणाली - कभी नहीं
• कोड ऑन डिमांड (वैकल्पिक) - संभव

Answer 8

खैर मैं दूसरे प्रश्न से शुरू करता हूं: वेब सेवा क्या हैं? , ज़ाहिर कारणों की वजह से।

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

निम्न लिंक यह बहुत ही आकर्षक तरीके से बाकी और SOAP के बारे में कहता है।

बाकी बनाम साबुन

यदि आप यह भी जानना चाहते हैं कि कब (REST या SOAP) क्या चुनना है, तो इसके माध्यम से जाने के सभी और कारण!

Answer 9

SOAP और REST दोनों एक दूसरे से बात करने के लिए विभिन्न प्रणालियों के तरीकों का उल्लेख करते हैं।

REST यह उन तकनीकों का उपयोग करता है, जो आपके ब्राउज़र में वेब सर्वर के साथ संचार के समान होती हैं: एक वेब पेज का अनुरोध करने के लिए GET का उपयोग करना, फॉर्म फील्ड में पोस्ट करना, आदि।

SOAP कुछ समान प्रदान करता है, लेकिन XML के ब्लॉक को आगे और पीछे भेजने के माध्यम से सब कुछ करता है। SOAP का एक अन्य प्रमुख घटक WSDL है जो एक XML दस्तावेज है जो बताता है कि कौन से फ़ंक्शन और डेटा तत्व समर्थित हैं। WSDL का उपयोग प्रोग्रामेटिक रूप से "डिस्कवर" के लिए किया जा सकता है कि प्रोग्रामिंग कोड स्टब्स उत्पन्न करने के लिए क्या फ़ंक्शन समर्थित हैं।

Comments

इसका REST से कोई लेना-देना नहीं है, यह सिर्फ 'HTTP का सही उपयोग' है

— aehlke

HTTP अपने आप में एक RESTful सिस्टम का सबसे अच्छा उदाहरण है।

— pbreitenbach

@pbreitenbach नहीं, HTTP नहीं है, यह मूल रूप से हाइपरमीडिया की कोई धारणा नहीं है। लेकिन अपने हाइपरलिंक्स और रूपों के साथ HTML एक Restful प्रणाली है। दरअसल, यह REST 'स्पेसिफिकेशन' का प्रोटोटाइप था

— Pavel Gatilov

SOAP आपको XML एन्कोडिंग का उपयोग करने के लिए बाध्य नहीं करता है। XML एन्कोडिंग का उपयोग केवल तभी किया जाता है जब कोई सेवा इंटरऑपरेबिलिटी प्रदान करती है। आंतरिक रूप से, POJO को XML में कोई एन्कोडिंग नहीं भेजा जा सकता है।

— koppor

Answer 10

मुझे लगता है कि यह उतना आसान है जितना मैं इसे समझा सकता हूं। कृपया, किसी का भी स्वागत है मुझे सुधारने के लिए या इसे जोड़ने के लिए।

SOAP एक संदेश प्रारूप है जिसका उपयोग डिस्कनेक्टेड सिस्टम (जैसे इंटरनेट पर) सूचना / डेटा के आदान-प्रदान के लिए किया जाता है। यह एक्सएमएल संदेशों को आगे और पीछे जाने के साथ करता है।

वेब सेवाएं SOAP संदेश प्रेषित या प्राप्त करती हैं। वे जिस भाषा में लिखे गए हैं, उसके आधार पर वे अलग-अलग तरीके से काम करते हैं।

Comments

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

— MyItchyChin

वेब सेवाएँ किस भाषा में लिखी जाती हैं, इसके आधार पर अलग-अलग तरीके से काम करते हैं। बस एक महत्वहीन अतिरिक्त विवरण।

— स्टिंगजैक

ठीक है, मुझे यकीन नहीं था कि अगर आप अनुमान लगा रहे हैं कि अंतर-व्यवधान के कारण कुछ है।

— MyItchyChin

Answer 11

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

Comments

यह आदर्शों के विरुद्ध है, और हमने केवल उस पर ध्यान दिया है। यह लगभग 1998 या उसके बाद से है, और हम केवल इसे उठा रहे हैं। अरे, हम मूर्ख हैं!

— जॉन साउन्डर्स

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

— निकोलस शैंक्स

"हम" सभी वेब डेवलपर नहीं हैं। हम में से कुछ बस चीजों को बेहतरीन तरीके से प्राप्त करने की कोशिश कर रहे हैं और परवाह नहीं करते हैं कि हम "वेब की पूरी क्षमता का उपयोग नहीं कर रहे हैं"।

— जॉन सॉन्डर्स

"मूर्ख" बस के बारे में यह, हाँ हाँ।

— रोब ग्रांट

Answer 12

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

Answer 13

SOAP - "सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल"

SOAP संदेशों को स्थानांतरित करने, या इंटरनेट पर थोड़ी मात्रा में जानकारी देने का एक छोटा सा हिस्सा है। SOAP संदेश XML में स्वरूपित किए जाते हैं और आमतौर पर HTTP को नियंत्रित करने के लिए भेजे जाते हैं ।

REST - "स्टेटिकेशनल स्टेट ट्रांसफर"

REST घटना की एक अल्पविकसित प्रक्रिया है और प्रशंसक और सर्वर के बीच जानकारी प्राप्त करता है और इसमें असमान रूप से परिभाषित कई मानक नहीं हैं। आप JSON , XML या यहां तक ​​कि सादे पाठ के रूप में जानकारी भेज और स्वीकार कर सकते हैं । यह SOAP की तुलना में हल्का है ।

Answer 14

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

हम अभी भी SOAP को XMLbased Remote Procedure Calls के साथ जोड़ सकते हैं, लेकिन SOAPbased Web Services Technology एक लचीली और शक्तिशाली मैसेजिंग मॉडल के रूप में उभरी है।

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

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

आरईएसटी - रिप्रेजेंटेशनल स्टेट ट्रांसफर। भौतिक प्रोटोकॉल HTTP है। असल में, REST यह है कि वेब पर सभी विशिष्ट संसाधन जो URL द्वारा विशिष्ट रूप से पहचाने जाने योग्य हैं। इन संसाधनों पर किए जा सकने वाले सभी ऑपरेशनों को क्रियाओं के सीमित सेट ("CRUD" क्रियाओं) द्वारा वर्णित किया जा सकता है, जो बदले में HTTP क्रियाओं का मानचित्र बनाते हैं।

REST SOAP की तुलना में बहुत कम "हैवीवेट" है।

वेब सेवा का कार्य

Comments

-1 आपके द्वारा कही गई लगभग सभी बातें गलत हैं। SOAP में विवरण नहीं है। डब्लूएसडीएल करता है। WSDL एक XML प्रारूप है - यह किसी भी प्रोटोकॉल पर "रन" नहीं करता है। SOAP को मिडलवेयर की आवश्यकता नहीं है। REST "वेब सेवाओं की दूसरी पीढ़ी" नहीं है। WADL एक मानक नहीं है। En.wikipedia.org/wiki/Web_Application_Description_Language देखें ।

— जॉन साउन्डर्स