SOAP बनाम बाकी (अंतर)

Question

मैंने वेब सेवा संचार प्रोटोकॉल के रूप में SOAP और REST के बीच के अंतर के बारे में लेख पढ़ा है, लेकिन मुझे लगता है कि SOAP पर REST के लिए सबसे बड़े लाभ हैं:

1. REST अधिक गतिशील है, UDDI (यूनिवर्सल विवरण, डिस्कवरी और एकीकरण) बनाने और अपडेट करने की कोई आवश्यकता नहीं है।

2. REST केवल XML प्रारूप तक ही सीमित नहीं है। श्रेष्ठ वेब सेवाएं सादे पाठ / JSON / XML भेज सकती हैं।

लेकिन SOAP अधिक मानकीकृत है (जैसे: सुरक्षा)।

तो, क्या मैं इन बिंदुओं में सही हूं?

Comments

एक अक्षर सादृश्य है जो मुझे SOAP बनाम REST के बारे में बहुत पसंद आया, SOAP के साथ आप एक लिफाफे का उपयोग कर रहे हैं, REST के साथ, यह एक पोस्टकार्ड है , तो जाहिर है SOAP में कुछ अतिरिक्त ओवरहेड हैं: अधिक बैंडविड्थ (अधिक कागज), दोनों पार्टियों के लिए अतिरिक्त काम ( लपेटकर और अपरिपक्व)। लेकिन इसका मतलब यह नहीं है कि REST SOAP जितना सुरक्षित नहीं है क्योंकि आप HTTPS का उपयोग कर सकते हैं (इसे ऐसे

— समझें

spf13.com/post/soap-vs-rest

— Migrate2Lazarus मेरी प्रोफ़ाइल देखें

nishantshukla001webservices.blogspot.in/2015/09/…

— Nico

"कई मायनों में, HTTP पर आधारित वर्ल्ड वाइड वेब, को REST- आधारित वास्तुकला के रूप में देखा जा सकता है।"

— अभिजीत

रिचर्डसन परिपक्वता मॉडल के अनुसार तीन चरणों में REST दृष्टिकोण के प्रमुख तत्वों को तोड़ता है, SOAP स्तर 0 REST है।

— सम्पदा

Answer 1

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

SOAP और REST की सीधे तुलना नहीं की जा सकती, क्योंकि पहला एक प्रोटोकॉल है (या कम से कम होने की कोशिश करता है) और दूसरा एक वास्तुशिल्प शैली है। यह शायद इसके आस-पास के भ्रम का एक स्रोत है, क्योंकि लोग REST को किसी HTTP API के नाम से पुकारते हैं जो SOAP नहीं है।

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

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

मुझे लगता है कि REST के बारे में यह समझने के लिए ये महत्वपूर्ण बिंदु हैं, और यह SOAP से अलग कैसे है:

• REST प्रोटोकॉल स्वतंत्र है। यह HTTP पर युग्मित नहीं है। बहुत पसंद है कि आप एक वेबसाइट पर एक ftp लिंक का अनुसरण कर सकते हैं, एक REST एप्लिकेशन किसी भी प्रोटोकॉल का उपयोग कर सकता है जिसके लिए एक मानकीकृत URI योजना है।

• REST HTTP विधियों में CRUD का मानचित्रण नहीं है। उस पर विस्तृत विवरण के लिए इस उत्तर को पढ़ें ।

• REST उतना ही मानकीकृत है जितना आप उपयोग कर रहे हैं। HTTP में सुरक्षा और प्रमाणीकरण को मानकीकृत किया जाता है, इसलिए HTTP पर REST करते समय आप इसका उपयोग करते हैं।

• REST हाइपरमीडिया और HATEOAS के बिना REST नहीं है । इसका मतलब यह है कि एक ग्राहक केवल प्रवेश बिंदु URI जानता है और संसाधनों को उन लिंक को वापस करना चाहिए जो ग्राहक को पालन करना चाहिए। उन फैंसी प्रलेखन जनरेटर जो एक REST API में आपके द्वारा किए जा सकने वाले सभी चीज़ों के लिए URI पैटर्न देते हैं, बिंदु को पूरी तरह से याद करते हैं। वे न केवल मानक का पालन करने वाले कुछ का दस्तावेजीकरण कर रहे हैं, बल्कि जब आप ऐसा करते हैं, तो आप ग्राहक को एपीआई के विकास में एक विशेष क्षण के लिए युग्मित कर रहे हैं, और एपीआई पर किसी भी बदलाव को दस्तावेज और लागू करना होगा, या यह टूट जाएगा।

• REST स्वयं वेब की स्थापत्य शैली है। जब आप स्टैक ओवरफ्लो में प्रवेश करते हैं, तो आप जानते हैं कि एक उपयोगकर्ता, एक प्रश्न और एक उत्तर क्या है, आप मीडिया प्रकार जानते हैं, और वेबसाइट आपको उनके लिंक प्रदान करती है। REST API को भी ऐसा ही करना है। यदि हमने वेब डिज़ाइन किया है जिस तरह से लोगों को लगता है कि REST किया जाना चाहिए, तो प्रश्न और उत्तर के लिंक के साथ एक होम पेज होने के बजाय, हमारे पास एक स्थैतिक दस्तावेज होगा जिसमें यह समझाया जाएगा कि प्रश्न देखने के लिए, आपको URI लेना होगा stackoverflow.com/questions/<id>, Id.id के साथ id बदलें और अपने ब्राउज़र पर पेस्ट करें। यह बकवास है, लेकिन यही कई लोग सोचते हैं कि REST है।

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

मन में ऊपर के साथ, आपको एहसास होगा कि जबकि REST XML तक सीमित नहीं हो सकता है, इसे किसी अन्य प्रारूप के साथ सही ढंग से करने के लिए आपको अपने लिंक के लिए कुछ प्रारूप को डिजाइन और मानकीकृत करना होगा। हाइपरलिंक XML में मानक हैं, लेकिन JSON में नहीं हैं। JSON के लिए मसौदा मानक हैं, जैसे HAL ।

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

Comments

दोनों में कोई भी चलेगा। मुद्दा यह है कि उपयोगकर्ताओं को URL कैसे मिलते हैं, न कि वे उनका उपयोग कैसे करते हैं। उन्हें किसी अन्य दस्तावेज़ के लिंक से खोज url प्राप्त करना चाहिए, दस्तावेज़ से नहीं। प्रलेखन समझा सकता है कि खोज संसाधन का उपयोग कैसे करें।

— पेड्रो वर्नक

@CristiPotlog मैंने कभी नहीं कहा कि SOAP किसी विशेष प्रोटोकॉल पर निर्भर है, मैं केवल इस बात पर जोर देता हूं कि REST कैसे नहीं है। आपके द्वारा भेजा गया दूसरा लिंक कहता है कि REST को HTTP की आवश्यकता है, जो गलत है।

— पेड्रो वेर्नेक

यदि आप एक बार फिर अपने एपीआई को कॉल करना चाहते हैं, तो हेटोस एक बाधा है !

— Orestis

@SachinKainth यहाँ उस के लिए एक जवाब है । आप CRUD का ऑप्‍शन HTTP तरीके से कर सकते हैं, लेकिन यह REST नहीं है, क्‍योंकि यह RFC में प्रलेखित के रूप में उन विधियों के अभिप्रेत अर्थ नहीं है।

— पेद्रो वेर्नेक

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

— राजन चौहान

Answer 2

RESTबनाम SOAPहै नहीं सही सवाल पूछने के लिए।

REST, के विपरीत SOAPहै नहीं एक प्रोटोकॉल।

RESTएक वास्तुकला शैली और नेटवर्क-आधारित सॉफ़्टवेयर आर्किटेक्चर के लिए एक डिज़ाइन है ।

RESTअवधारणाओं को संसाधन के रूप में संदर्भित किया जाता है। किसी संसाधन का प्रतिनिधित्व स्टेटलेस होना चाहिए। यह कुछ मीडिया प्रकार के माध्यम से दर्शाया गया है। मीडिया प्रकार में शामिल हैं XML, JSON, और RDF। घटकों द्वारा संसाधनों में हेरफेर किया जाता है। घटक एक समान यूनिफ़ॉर्म इंटरफेस के माध्यम से संसाधनों का अनुरोध और हेरफेर करते हैं। HTTP के मामले में, इस इंटरफेस मानक HTTP ऑप्स जैसे होते हैं GET, PUT, POST, DELETE।

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

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

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

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

राज्यविहीन

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

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

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

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

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

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

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

EDIT: टिप्पणियों के आधार पर अपडेट सामग्री

Comments

REST के पास उन ऑपरेशनों का पूर्वनिर्धारित सेट नहीं है जो CRUD ऑपरेशन हैं। CRUD संचालन के लिए HTTP तरीकों को मैप करना नेत्रहीन रूप से REST के आसपास सबसे आम गलत धारणाओं में से एक है। HTTP विधियों में बहुत अच्छी तरह से परिभाषित व्यवहार हैं जिनका CRUD से कोई लेना देना नहीं है, और REST को HTTP पर युग्मित नहीं किया गया है। उदाहरण के लिए, आपके पास RETR और STOR के अलावा कुछ भी नहीं है।

— पेड्रो वेर्नेक

इसके अलावा, services REST सेवाओं के बारे में आप क्या सोचते हैं? ' जहाँ तक मुझे पता है, आपके पास कुछ HTTP विधियाँ हैं जो डिफ़ॉल्ट रूप से उदासीन हैं, और यदि आपकी सेवा में किसी विशेष ऑपरेशन के लिए idempotence की आवश्यकता है, तो आपको उनका उपयोग करना चाहिए, लेकिन यह कहने का कोई मतलब नहीं है कि यह सेवा निष्प्राण है। इस सेवा में ऐसे संसाधन हो सकते हैं, जो किसी बेकार या गैर-बेरोजगार फैशन में प्रभावी हो सकते हैं।

— पेड्रो वेर्नेक

@ सेमी: कृपया चौथे बिंदु को हटा दें - "एक प्रतिष्ठित आर्किटेक्चर अंतर्निहित संचार प्रोटोकॉल के रूप में HTTP या SOAP का उपयोग कर सकता है"। इसकी गलत सूचना जो आप बता रहे हैं।

— Bruce_Wayne

Answer 3

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

पेलोड क्या है?

जब डेटा इंटरनेट पर भेजा जाता है, तो प्रसारित प्रत्येक इकाई में हेडर की जानकारी और भेजे जाने वाले वास्तविक डेटा दोनों शामिल होते हैं। हेडर पैकेट के स्रोत और गंतव्य की पहचान करता है, जबकि वास्तविक डेटा को पेलोड कहा जाता है । सामान्य तौर पर, पेलोड वह डेटा होता है जो किसी एप्लिकेशन की ओर से किया जाता है और डेस्टिनेशन सिस्टम द्वारा प्राप्त डेटा होता है।

अब, उदाहरण के लिए, मुझे एक टेलीग्राम भेजना है और हम सभी जानते हैं कि टेलीग्राम की कीमत कुछ शब्दों पर निर्भर करेगी।

तो मुझे नीचे बताएं कि इन दो संदेशों में से कौन सा एक सस्ता है?

<name>Arin</name>

या

"name": "Arin"

मुझे पता है कि आपका उत्तर दूसरा होगा, हालांकि दोनों एक ही संदेश का प्रतिनिधित्व करते हैं दूसरा एक लागत के बारे में सस्ता है।

इसलिए मैं यह कहने की कोशिश कर रहा हूं कि, JSON प्रारूप में नेटवर्क पर डेटा भेजना पेलोड के बारे में XML प्रारूप में भेजने की तुलना में सस्ता है ।

यहाँ SOAP पर REST का पहला लाभ या लाभ है । SOAP केवल XML का समर्थन करता है, लेकिन REST टेक्स्ट, JSON, XML आदि जैसे विभिन्न प्रारूप का समर्थन करता है और हम पहले से ही जानते हैं, यदि हम Json का उपयोग करते हैं तो निश्चित रूप से हम पेलोड के संबंध में बेहतर जगह पर होंगे।

अब, SOAP एकमात्र XML का समर्थन करता है, लेकिन इसके फायदे भी हैं।

वास्तव में! कैसे?

SOAP XML पर तीन तरह से निर्भर करता है - लिफाफा - जो संदेश में क्या है और इसे कैसे प्रोसेस करता है, इसे परिभाषित करता है।

डेटा प्रकारों के लिए एन्कोडिंग नियमों का एक सेट, और अंत में प्रक्रिया कॉल और प्रतिक्रियाओं का लेआउट एकत्र हुआ।

यह लिफाफा एक ट्रांसपोर्ट (HTTP / HTTPS) के माध्यम से भेजा जाता है, और एक RPC (दूरस्थ प्रक्रिया कॉल) को निष्पादित किया जाता है, और एक XML स्वरूपित दस्तावेज़ में जानकारी के साथ लिफाफा लौटाया जाता है।

महत्वपूर्ण बिंदु यह है कि SOAP के लाभों में से एक "सामान्य" परिवहन का उपयोग है, लेकिन REST HTTP / HTTPS का उपयोग करता है । SOAP अनुरोध भेजने के लिए लगभग किसी भी परिवहन का उपयोग कर सकता है लेकिन REST नहीं कर सकता। इसलिए यहां हमें SOAP का उपयोग करने का लाभ मिला।

जैसा कि मैंने पहले ही उपर्युक्त पैराग्राफ में कहा था “REST HTTP / HTTPS का उपयोग करता है” , इसलिए इन शब्दों पर थोड़ा और गहराई से जाएँ।

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

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

इसके अलावा, जैसा कि REST , HTTP प्रोटोकॉल द्वारा सीमित है, इसलिए यह लेन-देन का समर्थन न तो ACID का अनुपालन है और न ही वितरित ट्रांसनेशनल संसाधनों के लिए दो-चरण प्रतिबद्ध प्रदान कर सकता है।

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

मैं कोई निष्कर्ष नहीं निकाल रहा हूं, लेकिन मैं SOAP- आधारित वेब सेवा पसंद करूंगा, जबकि सुरक्षा, लेनदेन आदि मुख्य चिंताएं हैं।

यहां "द जावा ईई 6 ट्यूटोरियल" है, जहां उन्होंने कहा है कि निम्नलिखित स्थितियों को पूरा करने पर ए रिस्टफुल डिज़ाइन उपयुक्त हो सकता है । एक नज़र देख लो।

आशा है आपको मेरा उत्तर पढ़कर अच्छा लगा होगा।

Comments

शानदार उत्तर लेकिन याद रखें कि REST किसी भी परिवहन प्रोटोकॉल का उपयोग कर सकता है। उदाहरण के लिए, यह FTP का उपयोग कर सकता है।

— भार्गव नानकेलवा

किसने कहा कि REST SSL का उपयोग नहीं कर सकता है?

— ओसामा आफ़ताब

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

— बैक्टीरिया

XML डेटा के आकार के बारे में बिंदु को संदर्भित करने के लिए, जब संपीड़न सक्षम होता है, तो XML काफी छोटा होता है।

— GaTechThomas 18

पेलोड के आकार के बारे में बिंदु को हटा दिया जाना चाहिए, यह JSON और XML के बीच की एक-आयामी तुलना है और केवल गंभीर रूप से अनुकूलित सेटअपों में पता लगाना संभव है, जो अभी तक के बीच हैं।

— थॉमसआरएस

Answer 4

REST ( RE प्रेजेंटेशनल S tate T ransfer)
आर प्रेजेंटेशनल S tate of a object is T ransferred REST है अर्थात हम ऑब्जेक्ट नहीं भेजते हैं, हम ऑब्जेक्ट ऑफ़ स्टेट भेजते हैं। REST एक स्थापत्य शैली है। यह SOAP जैसे कई मानकों को परिभाषित नहीं करता है। REST डेटा पर CRUD संचालन को संभालने के लिए इंटरनेट पर सार्वजनिक एपीआई (यानी फेसबुक एपीआई, Google मैप्स एपीआई) को उजागर करने के लिए है। REST एकल सुसंगत इंटरफ़ेस के माध्यम से नामित संसाधनों तक पहुँचने पर केंद्रित है।

SOAP ( S imple O bject A ccess P rotocol)
SOAP अपना स्वयं का प्रोटोकॉल लाता है और सेवाओं के रूप में एप्लिकेशन लॉजिक (डेटा नहीं) के टुकड़ों को उजागर करने पर ध्यान केंद्रित करता है। SOAP संचालन को उजागर करता है। SOAP नाम संचालन तक पहुंचने पर केंद्रित है, प्रत्येक ऑपरेशन कुछ व्यावसायिक तर्क को लागू करता है। हालांकि SOAP को आमतौर पर वेब सेवाओं के रूप में संदर्भित किया जाता है यह मिथ्या नाम है। वेब के साथ कुछ भी करने के लिए SOAP बहुत कम है। REST URI और HTTP पर आधारित सही वेब सेवाएँ प्रदान करता है ।

क्यों?

• चूंकि REST मानक HTTP का उपयोग करता है इसलिए यह अभी तक के तरीके में बहुत सरल है।
• आरईएसटी को लागू करना आसान है, कम बैंडविड्थ और संसाधनों की आवश्यकता होती है।
• REST कई अलग-अलग डेटा स्वरूपों की अनुमति देता है, जहां SOAP केवल XML की अनुमति देता है।
• JSON के समर्थन के कारण REST ब्राउज़र क्लाइंट के लिए बेहतर समर्थन की अनुमति देता है।
• REST में बेहतर प्रदर्शन और मापनीयता है। बाकी रीड को कैश किया जा सकता है, SOAP आधारित रीड को कैश नहीं किया जा सकता है।
• अगर सुरक्षा एक बड़ी चिंता नहीं है और हमारे पास सीमित संसाधन हैं। या हम एक एपीआई बनाना चाहते हैं जो आसानी से सार्वजनिक रूप से अन्य डेवलपर्स द्वारा उपयोग किया जाएगा तो हमें REST के साथ जाना चाहिए।
• अगर हमें स्टेटलेस CRUD ऑपरेशन की जरूरत है तो REST के साथ जाएं।
• REST आमतौर पर सोशल मीडिया, वेब चैट, मोबाइल सेवाओं और Google मानचित्र जैसे सार्वजनिक एपीआई में उपयोग किया जाता है।
• एक ही संसाधन के लिए RESTful सेवा वापसी विभिन्न MediaTypes, अनुरोध हेडर पैरामीटर "स्वीकार" के रूप में पर निर्भर करता है application/xmlया application/jsonपोस्ट के लिए और /user/1234.jsonया प्राप्त /user/1234.xmlप्राप्त करने के लिए।
• बाकी सेवाओं को क्लाइंट-साइड एप्लिकेशन द्वारा बुलाया जाना चाहिए, न कि सीधे अंतिम उपयोगकर्ता को।
• REST में ST , S tate T ransfer से आता है । आप सर्वर को स्टोर करने के बजाय राज्य को चारों ओर स्थानांतरित करते हैं, यह REST सेवाओं को स्केलेबल बनाता है।

क्यों SOAP?

• SOAP को लागू करना बहुत आसान नहीं है और इसके लिए अधिक बैंडविड्थ और संसाधनों की आवश्यकता होती है।
• REST की तुलना में SOAP संदेश अनुरोध धीमा है और यह वेब कैशिंग तंत्र का उपयोग नहीं करता है।
• WS-Security: जबकि SOAP SSL (REST की तरह) का समर्थन करता है, यह WS-Security का भी समर्थन करता है, जो कुछ एंटरप्राइज़ सुरक्षा सुविधाओं को जोड़ता है।
• WS-AtomicTransaction: एक सेवा पर ACID लेन-देन की आवश्यकता है, आपको SOAP की आवश्यकता होगी।
• डब्लूएस-रिलाएबल मेसेजिंग: यदि आपके एप्लिकेशन को अतुल्यकालिक प्रसंस्करण और विश्वसनीयता और सुरक्षा की गारंटी स्तर की आवश्यकता है। बाकी के पास एक मानक संदेश प्रणाली नहीं है और उम्मीद करता है कि ग्राहक पुन: प्रयास करके संचार विफलताओं से निपटेंगे।
• यदि सुरक्षा एक बड़ी चिंता है और संसाधन सीमित नहीं हैं तो हमें SOAP वेब सेवाओं का उपयोग करना चाहिए। जैसे अगर हम पेमेंट गेटवे, फाइनेंशियल और टेलीकम्युनिकेशन से जुड़े काम के लिए एक वेब सर्विस बना रहे हैं तो हमें SOAP के साथ जाना चाहिए क्योंकि यहां हाई सिक्योरिटी की जरूरत होती है।

source1
सोर्स 2

Comments

REST क्रियाओं / विधियों का CRUD विधियों से 1 से 1 संबंध नहीं है, हालांकि, यह आरईएसटी शैली को समझने में शुरुआत में मदद कर सकता है।

— सैंटियागो मार्टी ओल्ब्रिच

REST SSL का समर्थन नहीं करता है? बाकी के लिए समान संसाधन url को https: // से शुरू नहीं किया जा सकता है?

— मौ

Answer 5

रेस्ट और सोप में अंतर

साबुन

1. SOAP एक प्रोटोकॉल है।
2. SOAP का अर्थ है सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल।
3. SOAP REST का उपयोग नहीं कर सकता क्योंकि यह एक प्रोटोकॉल है।
4. SOAP व्यावसायिक तर्क को उजागर करने के लिए सेवाओं के इंटरफेस का उपयोग करता है।
5. SOAP मानकों को कड़ाई से पालन करने को परिभाषित करता है।
6. SOAP को REST की तुलना में अधिक बैंडविड्थ और संसाधन की आवश्यकता होती है।
7. SOAP अपनी सुरक्षा को परिभाषित करता है।
8. SOAP XML डेटा फॉर्मेट को ही अनुमति देता है।
9. REST की तुलना में SOAP को कम पसंद किया जाता है।

आराम

1. REST एक स्थापत्य शैली है।
2. REST का अर्थ है प्रतिनिधि राज्य अंतरण।
3. REST SOAP वेब सेवाओं का उपयोग कर सकता है क्योंकि यह एक अवधारणा है और HTTP, SOAP जैसे किसी भी प्रोटोकॉल का उपयोग कर सकता है।
4. REST व्यवसाय तर्क को उजागर करने के लिए URI का उपयोग करता है।
5. REST SOAP जैसे बहुत अधिक मानकों को परिभाषित नहीं करता है।
6. REST को SOAP की तुलना में कम बैंडविड्थ और संसाधन की आवश्यकता होती है।
7. रेस्टफुल वेब सेवाएं अंतर्निहित परिवहन से सुरक्षा उपायों को विरासत में लेती हैं।
8. REST विभिन्न डेटा फॉर्मेट जैसे प्लेन टेक्स्ट, HTML, XML, JSON आदि की अनुमति देता है।
9. SOAP की तुलना में अधिक पसंदीदा।

अधिक जानकारी के लिए कृपया यहाँ देखें

Comments

क्या REST के तहत 3 और 6 विरोधाभासी नहीं हैं?

— दाराज़ेन बोजेलोवुक

हम सिर्फ एक दूसरे की विशेषता की तुलना करते हैं।

— रेक्स

Answer 6

IMHO आप SOAP और REST की तुलना नहीं कर सकते हैं, जहां वे दो अलग चीजें हैं।

SOAP एक प्रोटोकॉल है और REST एक सॉफ्टवेयर आर्किटेक्चरल पैटर्न है। SOAP बनाम REST के लिए इंटरनेट में बहुत गलत धारणा है ।

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

REST एक URL से एक सर्वर के राज्य (संसाधनों के रूप में) का प्रतिनिधित्व करता है। यह स्टेटलेस है और ग्राहकों को हाइपरमीडिया की समझ से परे सर्वर से बातचीत करने के लिए पूर्व ज्ञान नहीं होना चाहिए।

Answer 7

सबसे पहले: आधिकारिक तौर पर, सही प्रश्न web services + WSDL + SOAPबनाम होगा REST।

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

हालाँकि, व्यवहार में, हर कोई इसे अनदेखा करता है, तो आइए इसे भी अनदेखा करें

पहले से ही तकनीकी जवाब हैं, इसलिए मैं कुछ अंतर्ज्ञान प्रदान करने की कोशिश करूंगा।

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

• आपके द्वारा भेजे जाने वाले संदेश का प्रारूप क्या है
• संदेश को आगे और पीछे कैसे किया जाना चाहिए

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

दूसरे प्रश्न के लिए, विभिन्न उत्तर हैं। हालाँकि, व्यवहार में उपयोग किया जाने वाला एकमात्र SOAP है । इसका मुख्य विचार है: पिछले XML (वास्तविक संदेश) को अभी तक किसी अन्य XML (एन्कोडिंग जानकारी और अन्य सहायक सामग्री) में लपेटें, और इसे HTTP पर भेजें। HTTP का POST तरीका संदेश भेजने के लिए उपयोग किया जाता है, क्योंकि हमेशा एक शरीर होता है ।

इस पूरे दृष्टिकोण का मुख्य विचार यह है कि आप एक URL को किसी फ़ंक्शन में मैप करते हैं , अर्थात एक क्रिया के लिए । इसलिए, यदि आपके पास किसी सर्वर में ग्राहकों की सूची है, और आप एक को देखना / अपडेट / हटाना चाहते हैं, तो आपके पास 3 URL होना चाहिए:

• myapp/read-customer और संदेश के मुख्य भाग में, ग्राहक की आईडी को पढ़ा जाना चाहिए।
• myapp/update-customer और शरीर में, ग्राहक की आईडी और साथ ही नए डेटा को पास करें
• myapp/delete-customer और शरीर में आई.डी.

REST दृष्टिकोण चीजों को अलग तरह से देखता है। URL को किसी क्रिया का प्रतिनिधित्व नहीं करना चाहिए, लेकिन एक चीज़ (जिसे REST लिंगो में संसाधन कहा जाता है )। चूंकि HTTP प्रोटोकॉल (जिसे हम पहले से उपयोग कर रहे हैं) क्रियाओं का समर्थन करता है, उन क्रियाओं का उपयोग करें जो बताती हैं कि क्या क्रियाएं हैं करने के लिए करते हैं कि चीज़ पर करने हैं।

तो, REST दृष्टिकोण के साथ, ग्राहक संख्या 12 URL पर मिलेगी myapp/customers/12। ग्राहक डेटा देखने के लिए, आप URL को GET अनुरोध के साथ हिट करें। इसे हटाने के लिए, एक ही URL, DELETE क्रिया के साथ। इसे अपडेट करने के लिए, फिर से, वही URL जिसमें एक POST क्रिया है, और अनुरोध बॉडी में नई सामग्री है।

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

Comments

तुम्हारा क्या मतलब RESTहै वेब सेवा नहीं है ?? JAX-RSफिर क्या ??

— आशीष कांबले

@AishishKamble: मैंने बाकी सेवाओं के विनिर्देशन का लिंक प्रदान किया। आधिकारिक परिभाषा में केवल WS- * प्रोटोकॉल शामिल हैं (मोटे तौर पर जिन्हें हम "SOAP" कहते हैं) और बाकी आधिकारिक तौर पर इसका हिस्सा नहीं है

— ब्लू_नोट

@AishishKamble: इसके अलावा, ध्यान दें कि एक JAX-WS भी है, जिसका अर्थ है "वेब सेवाएं", "बाकी सेवाओं" से विभेदित। वैसे भी, अंतर किसी भी व्यावहारिक उद्देश्यों के लिए महत्वपूर्ण नहीं है, जैसा कि मैंने भी उल्लेख किया है।

— Blue_note

Answer 8

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

Answer 9

इसके लिए जोड़:

++ एक गलती जो अक्सर REST से संपर्क करते समय की जाती है, इसे "URL के साथ वेब सेवाओं" के रूप में सोचना चाहिए- REST को अन्य दूरस्थ प्रक्रिया कॉल (RPC) तंत्र के बारे में सोचें, जैसे कि SOAP, लेकिन सादे HTTP URL के माध्यम से और SOAP की विषमता के बिना लागू किया गया। XML नाम स्थान।

++ इसके विपरीत, REST का RPC के साथ बहुत कम संबंध है। जबकि RPC सेवा उन्मुख और कार्यों और क्रियाओं पर केंद्रित है, REST संसाधन उन्मुख है, जिसमें उन चीजों और संज्ञाओं पर जोर दिया जाता है जिनमें एक अनुप्रयोग शामिल होता है।

Answer 10

इनमें से बहुत सारे उत्तर हाइपरमीडिया नियंत्रण (HATEOAS) का उल्लेख करना पूरी तरह से भूल गए, जो कि REST के लिए पूरी तरह से मौलिक है। कुछ अन्य लोगों ने इसे छुआ, लेकिन वास्तव में इसे इतनी अच्छी तरह से नहीं समझाया।

इस लेख को विशिष्ट SOAP सुविधाओं पर मातम में पड़े बिना, अवधारणाओं के बीच के अंतर को स्पष्ट करना चाहिए।