rest प्रतिनिधि राज्य हस्तांतरण(आरईएसटी) और सरल ऑब्जेक्ट एक्सेस प्रोटोकॉल(एसओएपी)




soap (12)

यह सबसे सरल व्याख्या है जिसे आप कभी भी पा सकते हैं।

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

how-i-explained-rest-to-my-wife (मूल लिंक)
how-i-explained-rest-to-my-wife (2013-07-19 कामकाजी लिंक)

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


एसओएपी और आरईएसटी के बारे में सरल स्पष्टीकरण

एसओएपी - "सरल ऑब्जेक्ट एक्सेस प्रोटोकॉल"

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

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

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


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

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

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

प्रतिनिधि राज्य हस्तांतरण (आरईएसटी):

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

गूगल पर आरईएसटी बनाम एसओएपी पर अंतहीन बहसें हैं।

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


एसओएपी - सरल ऑब्जेक्ट एक्सेस प्रोटोकॉल एक प्रोटोकॉल है !

आरईएसटी - प्रतिनिधिमंडल राज्य हस्तांतरण एक वास्तुशिल्प शैली है !

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

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

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

मौलिक रीस्ट सिद्धांतों

ग्राहक-सर्वर संचार

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

राज्यविहीन

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

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

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

वर्दी इंटरफेस

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

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

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


एसओएपी और आरईएसटी दोनों अलग-अलग प्रणालियों के लिए एक दूसरे से बात करने के तरीकों का संदर्भ देते हैं।

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

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


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


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

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

निम्नलिखित लिंक आरईएसटी और एसओएपी के बारे में एक बेहद स्पष्ट तरीके से कहता है।

एसईएपी बनाम आरईएसटी

यदि आप यह भी जानना चाहते हैं कि (आरईएसटी या एसओएपी) क्या चुनना है, तो इसके माध्यम से जाने का और अधिक कारण!


एसओएपी - "सरल ऑब्जेक्ट एक्सेस प्रोटोकॉल"

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

आरईएसटी - "प्रतिनिधिमंडल राज्य हस्तांतरण"

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


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

आरईएसटी राज्य की जानकारी का आदान-प्रदान है, जितना संभव हो सके किया जाता है।

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

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

संपादित करें: किसी कारण से लिंक सही तरीके से प्रदर्शित नहीं हो रहे हैं। REST = REST

डब्ल्यूएस- * = http://en.wikipedia.org/wiki/WS- *


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

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

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


आराम

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

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

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

दुर्भाग्यवश, ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm को छोड़कर, वेब पर आरईएसटी पर सही जानकारी ढूंढना मुश्किल है। (वह वह है जिसने आरईएसटी ली है)। मैं 'अभ्यास में आरईएसटी' पुस्तक की सिफारिश करता हूं क्योंकि यह एसओएपी से आरईएसटी में विकसित होने के तरीके पर एक व्यापक चरण-दर-चरण ट्यूटोरियल देता है।

साबुन

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

तुलना

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

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

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

अद्यतन करें

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

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

आरईएसटी एपीआई परिभाषा के लिए अब विभिन्न प्रकार के टूल्स हैं । मेरी निजी वरीयता वर्तमान में RAML

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

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


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

साबुन

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

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

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

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

एसओएपी आरपीसी

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

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

आराम

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

आरईएसटी बाधाएं

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

    • संसाधनों की पहचान - आरईएसटी संसाधन RDF संसाधन के समान है। फील्डिंग के अनुसार यदि आप कुछ नाम दे सकते हैं, तो यह संसाधन हो सकता है, उदाहरण के लिए: "वर्तमान स्थानीय मौसम" संसाधन हो सकता है, या "आपका मोबाइल फोन" संसाधन हो सकता है, या "एक विशिष्ट वेब दस्तावेज़" हो सकता है संसाधन। संसाधन की पहचान करने के लिए आप संसाधन पहचानकर्ताओं का उपयोग कर सकते हैं: यूआरएल और यूआरएन (उदाहरण के लिए किताबों द्वारा आईएसबीएन संख्या )। एक पहचानकर्ता केवल एक विशिष्ट संसाधन से संबंधित होना चाहिए, लेकिन एक संसाधन में कई पहचानकर्ता हो सकते हैं, जिन्हें हम अक्सर उदाहरण के लिए https://example.com/api/v1/users?offset=50&count=25 जैसे यूआरएल के साथ पेजिनेशन द्वारा शोषण करते हैं। । यूआरएल में कुछ specifications , उदाहरण के लिए एक ही पेट के साथ यूआरएल लेकिन अलग-अलग प्रश्न समान नहीं हैं, या पथ भाग में यूआरएल के हायरहार्मल डेटा होना चाहिए और क्वेरी भाग में गैर-पदानुक्रमित डेटा होना चाहिए। आरईएसटी द्वारा यूआरएल बनाने के तरीके के बारे में ये मूल बातें हैं। Btw। यूआरएल संरचना केवल सेवा डेवलपर्स के लिए मायने रखती है, वास्तविक रीस्ट क्लाइंट इसके साथ चिंता नहीं करता है। एक और अक्सर पूछे जाने वाले प्रश्न एपीआई संस्करण है, जो एक आसान है, क्योंकि फील्डिंग के अनुसार संसाधन द्वारा एकमात्र निरंतर चीज अर्थशास्त्र है। यदि अर्थशास्त्र बदलते हैं, तो आप एक नया संस्करण संख्या जोड़ सकते हैं। आप शास्त्रीय 3 संख्या संस्करण का उपयोग कर सकते हैं और केवल यूआरएल ( https://example.com/api/v1/ ) में बड़ी संख्या जोड़ सकते हैं। तो पिछड़े संगत परिवर्तनों से कुछ भी नहीं होता है, गैर-पिछड़े संगत परिवर्तनों से आपके पास एक नई एपीआई रूट https://example.com/api/v2/ साथ एक गैर-पिछड़ा संगत अर्थशास्त्र होगा। तो पुराने ग्राहक नहीं तोड़ेंगे, क्योंकि वे पुराने semantics के साथ https://example.com/api/v1/ उपयोग कर सकते हैं।
    • प्रस्तुतियों के माध्यम से संसाधनों का कुशलता - आप संसाधनों के इच्छित प्रतिनिधित्व को भेजकर संसाधनों (संसाधन राज्य) से संबंधित डेटा का उपयोग कर सकते हैं - HTTP विधि और संसाधन पहचानकर्ता के साथ - आरईएसटी सेवा में। उदाहरण के लिए यदि आप शादी के बाद किसी उपयोगकर्ता का नाम बदलना चाहते हैं, तो आप एक 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"} प्रतिक्रिया। इसलिए हम क्लाइंट स्टेटस को बदलने के लिए इस प्रस्तुति का उपयोग कर सकते हैं, उदाहरण के लिए हम "हमारे पेज श्रीमती स्मिथ में आपका स्वागत है!" प्रदर्शित कर सकते हैं। संदेश। संसाधन संसाधन पहचानकर्ता (यूआरएल) या अनुरोध के साथ भेजे गए accept हेडर के आधार पर संसाधन में कई प्रस्तुतियां हो सकती हैं। उदाहरण के लिए यदि image/jpeg से अनुरोध किया जाता है तो हम श्रीमती स्मिथ (शायद नग्न नहीं) की एक छवि भेज सकते हैं।
    • स्व-वर्णनात्मक संदेश - संदेशों में उन्हें संसाधित करने के तरीके के बारे में जानकारी होनी चाहिए। उदाहरण के लिए यूआरआई और HTTP विधि, सामग्री-प्रकार शीर्षलेख, कैश हेडर, आरडीएफ जो डेटा के अर्थ का वर्णन करता है, आदि ... मानक विधियों का उपयोग करना महत्वपूर्ण है। HTTP विधियों के specification को जानना महत्वपूर्ण है। उदाहरण के लिए जीईटी का मतलब है अनुरोध यूआरएल द्वारा पहचाने गए सूचना को पुनर्प्राप्त करना, DELETE का मतलब है कि सर्वर को दिए गए यूआरएल द्वारा पहचाने गए संसाधन को हटाने के लिए सर्वर से पूछना है, और इसी तरह ... HTTP स्टेटस कोड के पास एक specification भी है, उदाहरण के लिए 200 का मतलब सफलता है, 201 का मतलब है एक नया संसाधन बनाया गया है, 404 का मतलब है कि अनुरोधित संसाधन सर्वर पर नहीं मिला था, आदि ... मौजूदा मानकों का उपयोग आरईएसटी का एक महत्वपूर्ण हिस्सा है।
    • हाइपरमीडिया आवेदन राज्य के इंजन के रूप में (बाद में हेटोआस) - हाइपरमीडिया एक मीडिया प्रकार है जिसमें हाइपरलिंक्स हो सकते हैं। वेब द्वारा हम लिंक का पालन करते हैं - एक हाइपरमीडिया प्रारूप (आमतौर पर एचटीएमएल) द्वारा वर्णित - एक लक्ष्य प्राप्त करने के लिए, एड्रेस बार में यूआरएल टाइप करने के बजाय। आरईएसटी एक ही अवधारणा का पालन करता है, सेवा द्वारा भेजे गए प्रस्तावों में हाइपरलिंक्स हो सकते हैं। हम सेवा के अनुरोध भेजने के लिए इन हाइपरलिंक्स का उपयोग करते हैं। प्रतिक्रिया के साथ हमें डेटा (और शायद अधिक लिंक) मिलते हैं जिनका उपयोग हम नए ग्राहक राज्य के निर्माण के लिए कर सकते हैं, और इसी तरह ... इसलिए यही कारण है कि हाइपर्मियाडिया आवेदन राज्य (क्लाइंट राज्य) का इंजन है। आप शायद आश्चर्य करते हैं कि ग्राहक हाइपरलिंक्स को कैसे पहचानते हैं और उनका पालन करते हैं? मनुष्यों द्वारा यह बहुत आसान है, हम लिंक का शीर्षक पढ़ते हैं, शायद इनपुट फ़ील्ड भर सकते हैं, और उसके बाद केवल एक क्लिक। मशीनों द्वारा हमें आरडीएफ ( JSON-LD द्वारा Hydra साथ) या हाइपरमीडिया विशिष्ट समाधान (उदाहरण के लिए आईएएनए लिंक रिलेशनशिप और HAL+JSON द्वारा विक्रेता विशिष्ट एमआईएम प्रकार ) के साथ लिंक में अर्थशास्त्र जोड़ना होगा। कई मशीन पठनीय XML और जेएसओएन हाइपर्मियाडिया प्रारूप हैं , उनमें से केवल एक छोटी सूची है:

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

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

आरईएसटी webservice - एसओएपी आरपीसी webservice मतभेद

तो एक आरईएसटी webservice एक एसओएपी webservice से बहुत अलग है (आरपीसी बाध्यकारी शैली और शाब्दिक एन्कोडिंग शैली के साथ)

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

और इसी तरह...

एक एसओएपी आरपीसी webservice सभी आरईएसटी बाधाओं को पूरा नहीं करता है:

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




soap