बाकी बनाम साबुन। भाग 1. अंतर महसूस करें

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

सामग्री की तालिका:

बाकी बनाम साबुन। भाग 1. अंतर महसूस करें।
बाकी बनाम साबुन। भाग 2. प्लेटफॉर्म संचार को व्यवस्थित करना कितना आसान और अधिक कुशल है?

कुछ महीने पहले, इस मुद्दे के सरसरी अध्ययन में, मुझे निम्नलिखित के बारे में REST के बारे में पता चला:

• सब कुछ एक अद्वितीय पहचानकर्ता (URL) वाला एक संसाधन है
• सभी क्लाइंट ऑपरेशन स्टेटलेस सर्वर के साथ, अर्थात सर्वर को किसी भी ग्राहक की जानकारी को किसी भी सत्र में संग्रहीत नहीं करना चाहिए
• सभी अनुरोधों को सीआरयूडी के अनुसार 4 प्रकारों में विभाजित किया जा सकता है, और प्रत्येक प्रकार को एचटीटीपी विधि से मैप किया जाता है - पोस्ट, गेट, पुट या डिलीट
• सभी तर्क संसाधनों के इर्द-गिर्द घूमते हैं, परिचालन के नहीं

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

यह समझना महत्वपूर्ण है कि REST एक प्रोटोकॉल या मानक नहीं है, बल्कि एक वास्तुशिल्प शैली है । इस शैली के अपने सिद्धांत हैं। मुझे उनके द्वारा पसंद किए गए स्रोत से कॉपी करें और टिप्पणी करें:

1. हर "चीज़" को एक आईडी दें।
   बहुत ही वांछनीय है।
2. चीजों को आपस में जोड़ते हैं।
   उदाहरण के लिए, मर्सिडीज C218 के बारे में एक पृष्ठ (प्रस्तुति) में, विशेष रूप से इस मॉडल के इंजन के बारे में एक पृष्ठ पर एक लिंक जोड़ना अच्छा होगा, ताकि जो लोग तुरंत वहां जा सकें, और इस पृष्ठ को खोजने में समय बर्बाद न करें।
3. मानक तरीकों का उपयोग करें।
   मेरा मतलब है, ग्राहक की अपनी ताकत और पैसे बचाएं, मानक HTTP विधियों का उपयोग करें, उदाहरण के लिए GET

     http://www.example.com/cars/00345 

   getCar जैसे अपने स्वयं के तरीकों को परिभाषित करने के बजाय डेटा प्राप्त करने के लिए? आईडी = 00345।
4. संसाधनों में कई प्रतिनिधित्व हो सकते हैं।
   एक्सएमएल या JSON में सॉफ्टवेयर प्रोसेसिंग के लिए एक ही डेटा वापस किया जा सकता है या किसी व्यक्ति द्वारा देखने के लिए एक सुंदर डिजाइन में लपेटा जा सकता है।
5. वैधानिक रूप से संवाद करें।
   हां, एक न्यायपूर्ण सेवा एक आदर्श न्यायालय की तरह होनी चाहिए - यह प्रतिवादी (ग्राहक) या भविष्य के अतीत के लिए ब्याज की नहीं होनी चाहिए - वह केवल फैसला सुनाता है (अनुरोध के जवाब में)।

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

1. एसओएपी प्रोटोकॉल और मानकों का एक पूरा परिवार है , जिसका सीधा अर्थ है कि यह मशीन प्रसंस्करण के दृष्टिकोण से एक भारी और अधिक जटिल विकल्प है। इसलिए, REST तेज है।
2. SOAP HTTP को ट्रांसपोर्ट प्रोटोकॉल के रूप में उपयोग करता है, जबकि REST इस पर आधारित है। इसका अर्थ है कि HTTP प्रोटोकॉल पर आधारित सभी मौजूदा विकास, जैसे सर्वर-स्तरीय कैशिंग, स्केलिंग, REST आर्किटेक्चर में काम करना जारी रखते हैं, और SOAP के लिए अन्य साधनों की तलाश की जानी चाहिए। इसके बजाय, SOAP सेवाओं को ऐसी पौराणिक संपत्ति प्राप्त होती है, जो HTTP के बजाय किसी भी ट्रांसपोर्ट लेयर प्रोटोकॉल के साथ काम करने की क्षमता रखती है, हालाँकि, अक्सर मृत भाषाओं में बड़ी संख्या में विकिपीडिया लेखों से चेल्याबिंस्क ट्यूब रोलिंग प्लांट के कर्मचारियों की तुलना में इसका अधिक व्यावहारिक लाभ नहीं होता है।
3. यह माना जाता है कि रेस्टफुल सेवाओं का विकास बहुत सरल है। यह शायद सच है यदि आप नोटपैड का उपयोग मुख्य विकास वातावरण के रूप में करते हैं, लेकिन हमारे अद्भुत विकास साधनों का उपयोग करते हुए, मैं खुद को इस कथन की वैधता पर संदेह करने की अनुमति दूंगा।
4. "REST बनाम SOAP" क्वेरी के लिए पहला Google परिणाम इस तथ्य पर केंद्रित है कि REST प्रतिक्रिया को विभिन्न स्वरूपों में प्रस्तुत किया जा सकता है, और SOAP XML के लिए बाध्य है। यह एक बहुत ही महत्वपूर्ण कारक है, बस जावास्क्रिप्ट से एक सेवा को कॉल करने की कल्पना करें, जिसका उत्तर हम निश्चित रूप से JSON में प्राप्त करना चाहते हैं।
5. "REST बनाम SOAP" को "सरलता बनाम मानक" के रूप में फिर से परिभाषित किया जा सकता है , जो इस तथ्य में प्रकट होता है कि SOAP के लिए हमारे पास वेब सेवा के संपूर्ण विवरण के लिए WSDL प्रोटोकॉल है, जो सभी समान अद्भुत विकास साधनों का उपयोग करते हुए, एक ही जादू करता है। हमारे लिए काम करो। REST की तरफ, हमारे पास एक रहस्यमय और अप्रयुक्त WADL प्रोटोकॉल है, जो सिद्धांत रूप में, आवश्यक नहीं है - यह सादगी के साथ हस्तक्षेप करता है।
6. पिछले पैराग्राफ का दूसरा पहलू त्रुटि हैंडलिंग है। SOAP में, यह पूरी तरह से मानकीकृत है, और REST लंबे समय से ज्ञात HTTP त्रुटि कोड का उपयोग कर सकता है (यदि आप इस विचार से गए थे कि यह स्पष्ट है और मैं यह क्यों लिख रहा हूं, तो आप लेख को ध्यान से पढ़ रहे हैं)।
7. कुछ के साथ शुरू करने के लिए, लेकिन मेरे पास एक आखिरी है। यह प्रमुख विचारों में से एक है। SOAP संचालन के साथ काम करता है, और REST संसाधनों के साथ काम करता है । यह तथ्य, रेस्टफुल सेवाओं में एक ग्राहक राज्य की कमी के साथ संयुक्त, हमें इस तथ्य की ओर ले जाता है कि लेनदेन या अन्य जटिल तर्क जैसी चीजों को "SOAP-no" लागू किया जाना चाहिए।

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



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

और विषय को महसूस करने के लिए कुछ कार्य:

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

इन कार्यों में आप किन दृष्टिकोणों का उपयोग करेंगे?

मैं इस तथ्य के बारे में भी लिखना चाहता था कि यह सब .NET डेवलपर देता है और इसे अपने स्वयं के प्रयोजनों के लिए कैसे उपयोग किया जाता है, लेकिन मैं देख रहा हूं कि लेख का थकाऊ सूचकांक महत्वपूर्ण है, इसलिए मैं इसे समाप्त कर दूंगा। इसी सूचक को कम करने के लिए, मैंने जानबूझकर सुरक्षा पहलुओं से परहेज किया और उदाहरण के लिए, इस सवाल का जवाब देते हुए "आरईएस आर्किटेक्चर में प्रमाणीकरण कैसे संभव है, अगर इस पूरे लेख के पाठक को बताया गया कि रेस्टफुल सेवा स्टेटलेस होनी चाहिए?"

और लेख का निष्कर्ष निम्नानुसार होगा:

1. अपने REST सिद्धांतों के साथ क्षेत्ररक्षण ने कुछ भी आविष्कार नहीं किया है , लेकिन बस एक शोध प्रबंध में एक साथ रखा है जो पहले से ही किसी न किसी रूप में मौजूद है और उल्लिखित है कि पहले से गठित नेटवर्क वास्तुकला से अधिकतम लाभ कैसे प्राप्त किया जाए।
2. SOAP और REST प्रतिस्पर्धी नहीं हैं । वे विभिन्न भार श्रेणियों का प्रतिनिधित्व करते हैं और यह संभावना नहीं है कि कोई कार्य होगा जिसके लिए यह कहना मुश्किल होगा कि उपयोग करने के लिए कौन सा दृष्टिकोण अधिक तर्कसंगत है - SOAP या REST। इसलिए, एक वेब सेवा के लिए वास्तुकला की पसंद में "धार्मिक" विश्वास उपयोगी होने की संभावना नहीं है। जो लोग नहीं जानते हैं कि कार्य का विश्लेषण कहां से शुरू करना है, मैं इस प्रस्तुति की सिफारिश कर सकता हूं। वे अक्सर REST जीतते हैं।