सोप बनाम। बाकी: वेब एपीआई सेवाओं के बीच अंतर

विषय - सूची:

Anonim

SOAP क्या है?

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

REST क्या है?

REST को विशेष रूप से मीडिया घटकों, फ़ाइलों या किसी विशेष हार्डवेयर डिवाइस पर ऑब्जेक्ट्स जैसे घटकों के साथ काम करने के लिए डिज़ाइन किया गया था। REST के सिद्धांतों पर परिभाषित किसी भी वेब सेवा को RestFul वेब सेवा कहा जा सकता है। एक आरामदायक सेवा आवश्यक घटकों के साथ काम करने के लिए GET, POST, PUT और DELETE की सामान्य HTTP क्रियाओं का उपयोग करेगी। REST का अर्थ है प्रतिनिधि राज्य अंतरण।

कुंजी प्रसार

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

सोप और रीस्ट के बीच अंतर

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

नीचे SOAP और REST के बीच मुख्य अंतर हैं

साबुन

आराम
  • SOAP का अर्थ है सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल
  • REST का अर्थ है प्रतिनिधि राज्य अंतरण
  • SOAP एक प्रोटोकॉल है। SOAP को एक विनिर्देशन के साथ डिजाइन किया गया था। इसमें एक डब्ल्यूएसडीएल फ़ाइल शामिल है जिसमें वेब सेवा के स्थान के अलावा वेब सेवा क्या करती है, इसकी आवश्यक जानकारी है।
  • REST एक वास्तुशिल्प शैली है जिसमें एक वेब सेवा को केवल Restful सेवा के रूप में माना जा सकता है यदि यह होने की बाधाओं का अनुसरण करती है
    1. ग्राहक सर्वर
    2. राज्यविहीन
    3. संचित करने योग्य
    4. स्तरित प्रणाली
    5. यूनिफ़ॉर्म इंटरफ़ेस
  • SOAP REST का उपयोग नहीं कर सकता क्योंकि SOAP एक प्रोटोकॉल है और REST एक वास्तुशिल्प पैटर्न है।
  • REST वेब सेवाओं के लिए अंतर्निहित प्रोटोकॉल के रूप में SOAP का उपयोग कर सकता है, क्योंकि अंत में यह सिर्फ एक वास्तुशिल्प पैटर्न है।
  • ग्राहक अनुप्रयोगों के लिए अपनी कार्यक्षमता को उजागर करने के लिए SOAP सेवा इंटरफेस का उपयोग करता है। SOAP में, WSDL फ़ाइल क्लाइंट को आवश्यक जानकारी प्रदान करती है जिसका उपयोग यह समझने के लिए किया जा सकता है कि वेब सेवा क्या सेवाएं प्रदान कर सकती है।
  • REST हार्डवेयर डिवाइस पर घटकों तक पहुँचने के लिए यूनिफ़ॉर्म सर्विस लोकेटर का उपयोग करता है। उदाहरण के लिए, यदि कोई ऐसी वस्तु है जो URL पर होस्ट किए गए कर्मचारी के डेटा को http: //demo.guru99 के रूप में दर्शाती है, तो नीचे कुछ यूआरआई हैं जो उन्हें एक्सेस करने के लिए मौजूद हो सकते हैं

    • http://demo.guru99.com/Employee

    http://demo.guru99.com/Employee/1
  • इसके उपयोग के लिए SOAP को अधिक बैंडविड्थ की आवश्यकता होती है। चूंकि एसओएपी संदेशों में इसके अंदर बहुत सारी जानकारी होती है, इसलिए एसओएपी का उपयोग करके डेटा ट्रांसफर की मात्रा आमतौर पर बहुत अधिक होती है।
int
  • जब सर्वर पर अनुरोध भेजे जाते हैं तो REST को अधिक बैंडविड्थ की आवश्यकता नहीं होती है। बाकी संदेश ज्यादातर सिर्फ JSON संदेशों से मिलकर बने होते हैं। नीचे एक वेब सर्वर को दिए गए JSON संदेश का एक उदाहरण है। आप देख सकते हैं कि संदेश का आकार SOAP से तुलनात्मक रूप से छोटा है।
    • {"city":"Mumbai","state":"Maharastra"}
  • SOAP केवल XML प्रारूप के साथ काम कर सकता है। जैसा कि SOAP संदेशों से देखा जाता है, पास किया गया सभी डेटा XML प्रारूप में है।
  • REST विभिन्न डेटा फॉर्मेट जैसे प्लेन टेक्स्ट, HTML, XML, JSON इत्यादि की अनुमति देता है, लेकिन डेटा ट्रांसफर करने के लिए सबसे पसंदीदा फॉर्मेट JSON है।

REST का उपयोग कब करें?

सबसे उच्च बहस योग्य विषयों में से एक है जब वेब सेवाओं को डिजाइन करते समय REST का उपयोग किया जाना चाहिए या SOAP का उपयोग कब किया जाना चाहिए। नीचे कुछ प्रमुख कारक दिए गए हैं जो यह निर्धारित करते हैं कि प्रत्येक तकनीक का उपयोग वेब सेवाओं के लिए किया जाना चाहिए REST सेवाओं का उपयोग निम्नलिखित उदाहरणों में किया जाना चाहिए

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

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

  • कैशिंग - यदि बहुत सारे अनुरोधों को कैश करना है तो REST एक सही समाधान है। कई बार, ग्राहक एक ही संसाधन के लिए कई बार अनुरोध कर सकते हैं। इससे सर्वर को भेजे जाने वाले अनुरोधों की संख्या बढ़ सकती है। कैश को लागू करने से, सबसे अक्सर पूछे जाने वाले प्रश्न परिणाम एक मध्यवर्ती स्थान में संग्रहीत किए जा सकते हैं। इसलिए जब भी ग्राहक किसी संसाधन के लिए अनुरोध करता है, तो वह पहले कैश की जांच करेगा। यदि संसाधन मौजूद हैं, तो यह सर्वर पर आगे नहीं बढ़ेगा। इसलिए कैशिंग, यात्रा की मात्रा को कम करने में मदद कर सकता है जो वेब सर्वर पर की जाती हैं।

  • कोडिंग में आसानी - कोडिंग रीस्ट सर्विसेज और बाद में कार्यान्वयन SOAP की तुलना में कहीं अधिक आसान है। इसलिए यदि वेब सेवाओं के लिए त्वरित जीत समाधान की आवश्यकता है, तो REST जाने का रास्ता है।

SOAP का उपयोग कब करें?

SOAP का उपयोग निम्न उदाहरणों में किया जाना चाहिए

  1. अतुल्यकालिक प्रसंस्करण और बाद में आह्वान - अगर कोई आवश्यकता है कि ग्राहक को विश्वसनीयता और सुरक्षा की गारंटी स्तर की आवश्यकता है तो SOAP 1.2 का नया SOAP मानक बहुत अधिक अतिरिक्त सुविधाएँ प्रदान करता है, खासकर जब सुरक्षा की बात आती है।

  2. संचार का एक औपचारिक साधन है - यदि क्लाइंट और सर्वर दोनों के बीच विनिमय प्रारूप पर एक समझौता है तो SOAP 1.2 इस प्रकार की बातचीत के लिए कठोर विनिर्देश देता है। एक उदाहरण एक ऑनलाइन क्रय साइट है जिसमें उपयोगकर्ता भुगतान करने से पहले एक कार्ट में आइटम जोड़ते हैं। मान लेते हैं कि हमारे पास एक वेब सेवा है जो अंतिम भुगतान करती है। एक दृढ़ समझौता हो सकता है कि वेब सेवा केवल कार्ट आइटम नाम, इकाई मूल्य और मात्रा को स्वीकार करेगी। यदि ऐसा परिदृश्य मौजूद है, तो SOAP प्रोटोकॉल का उपयोग करना हमेशा बेहतर होता है।

  3. स्टेटफुल ऑपरेशंस - यदि एप्लिकेशन की आवश्यकता है कि राज्य को एक अनुरोध से दूसरे में बनाए रखने की आवश्यकता है, तो SOAP 1.2 मानक ऐसी आवश्यकताओं का समर्थन करने के लिए WS * संरचना प्रदान करता है।

सोप एपीआई में चुनौतियां

API को एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस के रूप में जाना जाता है और इसे क्लाइंट और सर्वर दोनों द्वारा प्रस्तुत किया जाता है। क्लाइंट की दुनिया में, यह ब्राउज़र द्वारा पेश किया जाता है जबकि सर्वर की दुनिया में यह वही है जो वेब सेवा द्वारा प्रदान किया जाता है जो या तो SOAP या REST हो सकता है।

सोप एपीआई के साथ चुनौतियां

  1. WSDL फ़ाइल - SOAP एपीआई की प्रमुख चुनौतियों में से एक WSDL दस्तावेज़ ही है। डब्लूएसडीएल दस्तावेज़ वह है जो वेब सेवा द्वारा निष्पादित किए जाने वाले सभी कार्यों के क्लाइंट को बताता है। WSDL दस्तावेज़ में सभी जानकारी होगी जैसे SOAP संदेशों में उपयोग किए जा रहे डेटा प्रकार और वेब सेवा के माध्यम से सभी ऑपरेशन उपलब्ध हैं। नीचे दिए गए कोड स्निपेट नमूना WSDL फ़ाइल का एक हिस्सा है।

उपरोक्त WSDL फ़ाइल के अनुसार, हमारे पास "TutorialName" नामक एक तत्व है जो स्ट्रिंग का प्रकार है जो तत्व TutorialNameRequest का एक हिस्सा है।

अब, मान लीजिए कि WSDL फ़ाइल को व्यावसायिक आवश्यकताओं के अनुसार बदलना है और TutorialName को TutorialDescription बनना है। इसका मतलब यह होगा कि वे सभी ग्राहक जो वर्तमान में इस वेब सेवा से जुड़ रहे हैं, तब उन्हें WSDL फ़ाइल में परिवर्तन को समायोजित करने के लिए अपने कोड में इसी परिवर्तन करने की आवश्यकता होगी।

यह डब्लूएसडीएल फ़ाइल की सबसे बड़ी चुनौती है जो क्लाइंट और सर्वर के बीच तंग अनुबंध है और यह एक परिवर्तन पूरे, क्लाइंट अनुप्रयोगों पर एक बड़ा प्रभाव पैदा कर सकता है।

  1. दस्तावेज़ का आकार - अन्य महत्वपूर्ण चुनौती SOAP संदेशों का आकार है जो क्लाइंट से सर्वर पर स्थानांतरित हो जाते हैं। बड़े संदेशों के कारण, SOAP का उपयोग उन जगहों पर किया जाता है जहां बैंडविड्थ एक बड़ी समस्या है।

बाकी एपीआई में चुनौतियां

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

सोप बनाम कोरबा बनाम डीसीओएम बनाम जावा आरएमआई के बीच अंतर

SOAP और REST के साथ आने से पहले RPC जैसी रिमोट एक्सेस तकनीक (दूरस्थ प्रक्रिया कॉल) विधियाँ आम उपयोग में थीं। विभिन्न दूरस्थ पहुँच तकनीकें जो उपलब्ध थीं, नीचे उल्लिखित हैं।

  1. CORBA - यह कहा जाता था सी ommon हे bject आर equest बी Roker एक rchitecture। यह व्यवस्था यह सुनिश्चित करने के लिए की गई थी कि विभिन्न प्लेटफार्मों पर बनाए गए एप्लिकेशन एक-दूसरे से बात कर सकें। CORBA एक ऑब्जेक्ट-ओरिएंटेड आर्किटेक्चर पर आधारित था, लेकिन इस आर्किटेक्चर पर आधारित होने के लिए कॉलिंग एप्लिकेशन का होना जरूरी नहीं था। इस तकनीक का मुख्य नुकसान यह था कि इसे इंटरफ़ेस परिभाषा भाषा नामक एक अलग भाषा में विकसित किया जाना था, और इसने केवल एक अतिरिक्त भाषा प्रस्तुत की जिसे डेवलपर्स द्वारा कोरबा प्रणाली का उपयोग करने के लिए सीखा जाना था।

  2. DCOM - यह D istributed C omponent O bject M odel है, जो रिमोट प्रॉसेस को एक्सेस करने के लिए क्लाइंट्स के लिए एक मालिकाना Microsoft टेक्नोलॉजी है। इस तंत्र के साथ सबसे बड़ा मुद्दा यह था कि क्लाइंट एप्लिकेशन तक संसाधनों को मुक्त करने के लिए जब आवश्यक नहीं था।

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

  3. जावा RMI - जावा के रूप में जाना आर भाव का प्रकट एम ethod मैं nvocation, यह कैसे दूरस्थ वस्तुओं दूरस्थ प्रक्रिया कॉल के माध्यम से कहा जा सकता है पर जावा कार्यान्वयन था। इस तकनीक का सबसे बड़ा प्रतिबंध यह था कि जावा आरएमआई केवल एक जावा वर्चुअल मशीन पर चलाया जा सकता था। इसका मतलब यह था कि जावा आरएमआई का उपयोग करने के लिए कॉलिंग एप्लिकेशन को जावा फ्रेमवर्क पर भी चलना होगा।

SOAP और इन तकनीकों के बीच मुख्य अंतर निम्नानुसार हैं

  1. HTTP पर काम करना - सभी RPC तकनीकों में एक बड़ी सीमा है, और वह यह है कि वे HTTP प्रोटोकॉल द्वारा काम नहीं करते हैं। चूंकि वेब पर सभी अनुप्रयोगों को इस प्रोटोकॉल पर काम करना पड़ता था, इसलिए यह उन क्लाइंट के लिए एक प्रमुख मार्ग हुआ करता था, जिन्हें इन RPC- शैली वेब सेवाओं तक पहुंच प्राप्त करनी थी।
  2. गैर-मानक बंदरगाहों के साथ काम करना - चूंकि HTTP प्रोटोकॉल द्वारा RPC शैली की वेब सेवाएँ काम नहीं करती थीं, इसलिए क्लाइंट के लिए इन वेब सेवाओं से कार्यक्षमता तक पहुँचने के लिए अलग से पोर्ट खोलना पड़ता था।