क्या आप अपने ऐप को फेसबुक से लिंक करना चाहते हैं ताकि यह स्वचालित रूप से पोस्ट उत्पन्न कर सके, या इंस्टाग्राम से ताकि आप कुछ हैशटैग के साथ तस्वीरें दोबारा पोस्ट कर सकें?
आप अपनी वेबसाइट पर YouTube वीडियो भी शामिल करना चाह सकते हैं। एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस आपको इन सभी कार्यों और अधिक (एपीआई) को निष्पादित करने की अनुमति देता है।
इंस्टाग्राम एपीआई, फेसबुक एपीआई और यूट्यूब एपीआई जैसे एपीआई की बदौलत विभिन्न एप्लिकेशन सुरक्षित और मानकीकृत तरीके से एक दूसरे से "बात" कर सकते हैं।
दूसरे शब्दों में, एक प्रोग्राम सॉफ़्टवेयर के किसी अन्य भाग से सुविधाएँ या डेटा ले सकता है और उनका उपयोग अपनी सुविधाओं या उपयोगकर्ता अनुभव को बेहतर बनाने के लिए कर सकता है। लेकिन ऐप्स ये अनुरोध कैसे कर सकते हैं, उन पर कार्रवाई कैसे कर सकते हैं और उन पर इस तरह से प्रतिक्रिया कैसे दे सकते हैं कि अन्य लोग समझ सकें?
यह इस पर निर्भर करता है कि एपीआई कैसे बनाया गया था। एपीआई (एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस) डिज़ाइन पर चर्चा करते समय, एसओएपी बनाम आरईएसटी, दो सबसे प्रमुख एपीआई प्रतिमानों की तुलना करना सामान्य है।
जैसे ही SOAP API (सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल) Oracle, Sun और PayPal जैसी कंपनियों के लिए स्वर्ण मानक बन गया, उसके एक साल बाद Google, Amazon और eBay से REST API के प्रति समान और विपरीत प्रतिक्रिया हुई।
इस पोस्ट में, हम SOAP API की तुलना REST API से करेंगे ताकि आप तय कर सकें कि आपके उद्देश्यों के लिए कौन सा सबसे अच्छा है।
हम एपीआई को परिभाषित करके शुरुआत करेंगे।
एपीआई क्या है?
एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस को एपीआई कहा जाता है। एपीआई मूलतः तरीकों और कार्यों का एक संग्रह है जो ऐप्स के विकास को सक्षम बनाता है। उन्हें विभिन्न कार्यक्रमों, सेवाओं या ऑपरेटिंग सिस्टम की जानकारी और कार्यों तक पहुंच मिलती है।
वे विभिन्न सॉफ्टवेयर प्रणालियों के बीच एक प्रकार के मध्यस्थ के रूप में कार्य करते हैं। वे दो असंबद्ध कार्यक्रमों के बीच "बातचीत" सक्षम करते हैं।
आइए एक स्टॉकब्रोकर का उदाहरण लें जो व्यापार और वित्तीय बाजारों में सक्रिय रूप से शामिल है। स्वचालित का एक संग्रह ट्रेडिंग एल्गोरिदम एपीआई के माध्यम से व्यापारी के पसंदीदा ट्रेडिंग ब्रोकर प्लेटफॉर्म से जोड़ा जा सकता है। यह आपको, व्यापारी को, इलेक्ट्रॉनिक लेनदेन निष्पादित करने या वास्तविक समय कोटेशन और मूल्य निर्धारण डेटा देखने में सक्षम बनाता है।
आरईएसटी क्या है?
सच्ची "वेब सेवाएँ" एपीआई में REST (प्रतिनिधि राज्य स्थानांतरण) शामिल है। REST API URI (यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर, जिनमें से URL एक विशेष प्रकार का होता है), HTTP प्रोटोकॉल और अविश्वसनीय ब्राउज़र-संगत JSON डेटा प्रारूप पर बनाए जाते हैं।
SOAP प्रोटोकॉल, जैसा कि हमने पहले ही कहा है, संभवतः इसका भी उपयोग किया जा सकता है। REST API बनाना और विकसित करना आसान हो सकता है, लेकिन वे विशाल और कठिन भी हो सकते हैं - यह सब इस बात पर निर्भर करता है कि वे कैसे बनाए गए, विस्तारित किए गए और वे क्या करने का इरादा रखते हैं।
संसाधन की कमी, कम सुरक्षा आवश्यकताएं, ब्राउज़र क्लाइंट संगतता, खोज क्षमता, डेटा स्वास्थ्य और स्केलेबिलिटी कुछ कारण हैं जिनसे आप एक एपीआई को रेस्टफुल विकसित करना चाहेंगे - ये चीजें वास्तव में वेब सेवाओं पर लागू होती हैं।
REST अधिक हल्का विकल्प प्रदान करता है। SOAP का उपयोग करना कठिन था और कई डेवलपर्स के लिए बोझ था। उदाहरण के लिए, जावास्क्रिप्ट के साथ SOAP का उपयोग करने के लिए सरल ऑपरेशन को पूरा करने के लिए बहुत सारे कोड लिखने की आवश्यकता होती है क्योंकि हर बार आवश्यक XML संरचना बनाई जानी चाहिए।
REST (आम तौर पर) XML अनुरोध के स्थान पर एक सीधा URL का उपयोग करता है। हालाँकि ऐसी दुर्लभ परिस्थितियाँ होती हैं जब आपको अधिक विवरण देना पड़ता है, अधिकांश RESTful वेब सेवाएँ केवल URL तकनीक का उपयोग करती हैं।
चार HTTP 1.1 क्रियाएं GET, POST, PUT, और DELETE का उपयोग REST द्वारा संचालन करने के लिए किया जा सकता है। SOAP के विपरीत, REST को XML में उत्तर की आवश्यकता नहीं है।
REST-आधारित वेब सेवाएँ जो कमांड सेपरेटेड वैल्यू (CSV), जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (JSON), और रियली सिंपल सिंडिकेशन (RSS) फॉर्मेट में डेटा आउटपुट करती हैं, उपलब्ध हैं (RSS)।
इसका उद्देश्य यह है कि आप अपने एप्लिकेशन के लिए जिस भाषा का उपयोग कर रहे हैं, उसके भीतर आसानी से पार्स किए जाने वाले प्रारूप में अपने आवश्यक परिणाम प्राप्त कर सकें।
विशेषताएं
- HTTP प्रोटोकॉल के कारण, REST बाकी सब से ऊपर सरलता पर जोर देता है।
- वेब REST के लिए सबसे उपयुक्त है। यह ब्राउज़र के साथ संगत है क्योंकि JSON का उपयोग डेटा प्रारूप के रूप में किया जाता है।
- REST अपनी उत्कृष्ट मापनीयता और गति के लिए प्रसिद्ध है।
- क्लाइंट-सर्वर कनेक्शन और आर्किटेक्चर को REST API द्वारा अधिक सुलभ बनाया गया है। यदि यह रेस्टफुल है, तो इसका निर्माण इस क्लाइंट-सर्वर मॉडल का उपयोग करके किया जाता है, जिसमें डेटा पेलोड पास करने वाले दोनों पक्षों के बीच राउंड ट्रिप होती है।
- REST API एक एकल मानक इंटरफ़ेस का उपयोग करते हैं। यह सुनिश्चित करना कि सभी ऐप्स समान रूप से और एक ही गेटवे के माध्यम से कनेक्ट हों, यह सुव्यवस्थित करता है कि एप्लिकेशन एपीआई के साथ कैसे संचार करते हैं।
SOAP क्या है?
इसका अपना प्रोटोकॉल, जिसे SOAP (सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल) कहा जाता है, REST की तुलना में थोड़ा अधिक जटिल है क्योंकि यह सुरक्षा और संदेश वितरण से संबंधित मानकों सहित अधिक मानकों को निर्दिष्ट करता है।
ये अंतर्निहित मानदंड थोड़े अतिरिक्त खर्च के साथ आते हैं। हालाँकि, वे उन व्यवसायों के लिए एक निर्णायक कारक हो सकते हैं जिन्हें अधिक व्यापक सुरक्षा, लेनदेन और ACID (एटोमिसिटी, कंसिस्टेंसी, आइसोलेशन, ड्यूरेबिलिटी) अनुपालन क्षमताओं की आवश्यकता होती है।
इस तुलना के लिए, यह ध्यान रखना महत्वपूर्ण है कि SOAP के कई लाभ अक्सर वेब सेवा अनुप्रयोगों पर लागू नहीं होते हैं, जिससे वे एंटरप्राइज़-प्रकार के परिदृश्यों के लिए अधिक उपयुक्त हो जाते हैं।
सुरक्षा की उच्च डिग्री (जैसे कि जब ए मोबाइल एप्लिकेशन बैंक के साथ इंटरैक्ट करता है), मैसेजिंग ऐप्स जिनके लिए भरोसेमंद संचार की आवश्यकता होती है, विरासत प्रणालियों के साथ इंटरैक्ट करना, या एसीआईडी अनुपालन ऐसे कुछ कारण हैं जिनकी वजह से आप SOAP एपीआई का उपयोग करके एक एप्लिकेशन डिज़ाइन करना चाहेंगे।
SOAP द्वारा दी जाने वाली मैसेजिंग क्षमताएं पूरी तरह से XML पर आधारित हैं। पुरानी इंटरनेट-असंगत तकनीकों जैसे डिस्ट्रीब्यूटेड कंपोनेंट ऑब्जेक्ट मॉडल (DCOM) और कॉमन ऑब्जेक्ट रिक्वेस्ट ब्रोकर आर्किटेक्चर को SOAP द्वारा प्रतिस्थापित किया गया था जब इसे पहली बार Microsoft (CORBA) द्वारा बनाया गया था।
बाइनरी संचार पर निर्भरता के कारण ये सिस्टम विफल हो जाते हैं। इंटरनेट पर, SOAP द्वारा उपयोग की जाने वाली XML मैसेजिंग बेहतर कार्य करती है।
विशेषताएं
- SOAP की सुरक्षा काफी कड़ी है. डब्लूएस-सुरक्षा एक अंतर्निहित मानक है जो एसएसएल समर्थन के अलावा जरूरत पड़ने पर एसओएपी अतिरिक्त उद्यम-स्तरीय सुरक्षा क्षमताएं प्रदान करता है।
- भरोसेमंद मैसेजिंग प्रदर्शन के लिए सफल/पुनः प्रयास करें। क्योंकि REST में मानकीकृत संदेश तंत्र का अभाव है, यह केवल संचार विफल होने पर ही पुनः प्रयास कर सकता है। यहां तक कि SOAP मध्यवर्ती का उपयोग करते समय भी, SOAP अपने अंतर्निहित सफल/पुनः प्रयास तर्क के कारण शुरू से अंत तक निर्भरता प्रदान करता है।
- SOAP पहले से ही ACID मानकों का अनुपालन करता है। यह निर्धारित करके कि लेनदेन डेटाबेस के साथ कैसे इंटरैक्ट कर सकता है, ACID अनुपालन विसंगतियों को कम करता है और डेटाबेस की स्थिरता की सुरक्षा करता है। क्योंकि ACID अन्य डेटा स्थिरता मॉडल की तुलना में अधिक सतर्क है, इसका उपयोग अक्सर संवेदनशील लेनदेन का प्रबंधन करते समय किया जाता है, चाहे वित्तीय हो या अन्यथा।
- प्रोग्रामर्स के लिए इसे समझना आसान है क्योंकि SOAP पूरी तरह से XML-आधारित संचार है।
- XML मैसेजिंग प्रोटोकॉल HTTP प्रोटोकॉल का एक अतिरिक्त है।
- SOAP मैसेजिंग के माध्यम से एक कंप्यूटर से दूसरे कंप्यूटर तक संचार प्रसारित किया जा सकता है।
- क्लाइंट-सर्वर आर्किटेक्चर को भी लागू किया जा सकता है। SOAP प्रोटोकॉल संदेश का उपयोग क्लाइंट द्वारा सर्वर-साइड स्थित दूरस्थ प्रक्रिया कॉल को कॉल करने के लिए किया जा सकता है।
REST बनाम SOAP अंतर
1। आर्किटेक्चर
एक एपीआई का उद्देश्य मुख्य रूप से किसी सर्वर पर किसी एप्लिकेशन के व्यावसायिक तर्क के विशिष्ट घटकों को दिखाना है। जबकि REST इसी उद्देश्य के लिए URI का उपयोग करता है, SOAP इसके लिए एक सेवा इंटरफ़ेस का उपयोग करता है।
REST API डेटा के बाद बनाए जाते हैं, जबकि SOAP API उन कार्यात्मकताओं के बाद विकसित किए जाते हैं जो API दिखाता है। SOAP की तुलना में, जो अधिक फ़ंक्शन-संचालित है, REST एक अधिक डेटा-संचालित डिज़ाइन है।
2। कैशिंग
जिस डेटा को कैश करने योग्य के रूप में चिह्नित किया गया है, उसे ब्राउज़र द्वारा सर्वर से नया अनुरोध किए बिना दोबारा उपयोग किया जा सकता है। इससे समय और मेहनत की बचत होती है।
प्रतिक्रियाओं को HTTP स्तर पर कैश नहीं किया जाएगा क्योंकि SOAP क्वेरीज़ POST अनुरोधों के माध्यम से सबमिट की जाती हैं, जिसे HTTP मानक गैर-निष्क्रिय मानता है। यदि आप कैशिंग का उपयोग करना चाहते हैं, तो आपको अभी भी आवश्यक तकनीकों का निर्माण करना होगा क्योंकि REST API में यह कार्यान्वयन शामिल नहीं है।
3. संसाधन और बैंडविड्थ
SOAP द्वारा उपयोग किए जाने वाले लिफाफा-शैली पेलोड ट्रांसफर के कारण, ओवरहेड में मामूली वृद्धि हुई है, जिसके लिए अतिरिक्त बैंडविड्थ की आवश्यकता होती है। REST की हल्की प्रकृति इन स्थितियों में फायदेमंद है क्योंकि इसका उपयोग आम तौर पर वेब सेवाओं के लिए किया जाता है।
4. सुरक्षा
डब्ल्यूएस-सुरक्षा, जो एसओएपी समर्थन करती है और परिवहन स्तर पर एसएसएल की तुलना में थोड़ी अधिक गहन है, वांछनीय है। इसके साथ उद्यम-स्तरीय सुरक्षा उपायों को शामिल करना भी बिल्कुल उपयुक्त है।
SSL का उपयोग करके एंड-टू-एंड एन्क्रिप्शन SOAP और REST दोनों द्वारा समर्थित है, और REST HTTP प्रोटोकॉल के सुरक्षित संस्करण HTTPS का उपयोग कर सकता है।
5. पेलोड को संभालना
इंटरनेट के माध्यम से प्रसारित डेटा को पेलोड कहा जाता है। एक पेलोड जिसे "भारी" माना जाता है उसे अतिरिक्त संसाधनों की आवश्यकता होती है। SOAP की तुलना में, जो XML का उपयोग करता है, REST अक्सर पेलोड को कम करने में सहायता के लिए JSON और HTTP का उपयोग करता है।
जनरेट किए गए कोड के साथ एक विशेष क्लाइंट लाइब्रेरी का उपयोग आमतौर पर क्लाइंट द्वारा उनके बेहद कड़े संचार अनुबंध के कारण SOAP एपीआई तक पहुंचने के लिए किया जाना चाहिए।
परिणामस्वरूप, SOAP REST की तुलना में कम स्तर का अमूर्तन प्रदान करता है और सर्वर के साथ अधिक निकटता से जुड़ा होता है।
आरईएसटी का उपयोग कब करें?
- सार्वजनिक एपीआई बनाना: सार्वजनिक वेब सेवाओं के निर्माण के लिए REST API को प्राथमिकता दी जाती है क्योंकि उन्हें SOAP API की तुलना में उपयोग करना और अपनाना आसान माना जाता है। इसके अतिरिक्त, SOAP कई अंतर्निहित सुरक्षा उपाय प्रदान करता है जो REST के पास नहीं हैं, हालाँकि खुले डेटा और सेवाओं के साथ काम करते समय इन विशेषताओं की आवश्यकता नहीं होती है।
- मोबाइल ऐप्स का निर्माण: REST मोबाइल एप्लिकेशन बनाने के लिए एकदम सही है क्योंकि यह छोटा, प्रभावी, स्टेटलेस और कैशेबल है।
- दुर्लभ सर्वर संसाधनों और बैंडविड्थ का उपयोग करना: REST API के सभी अनुरोध स्टेटलेस होने चाहिए, जिसका अर्थ है कि प्रत्येक इंटरैक्शन अलग है और प्रत्येक अनुरोध और प्रतिक्रिया में उस इंटरैक्शन को पूरा करने के लिए आवश्यक सभी डेटा शामिल हैं। सर्वर पिछले अनुरोधों के रिकॉर्ड सहेजता नहीं है क्योंकि यह प्रत्येक को एक ताज़ा अनुरोध मानता है। परिणामस्वरूप, सर्वर को बहुत कम मेमोरी की आवश्यकता होती है और यह अधिक तेज़ी से संचालित होता है क्योंकि अनुरोध के लिए आगे की कार्रवाई या ऐतिहासिक डेटा की पुनर्प्राप्ति की आवश्यकता नहीं होती है।
साबुन का उपयोग कब करें?
- विशेष रूप से बड़े व्यवसायों के लिए निजी एपीआई बनाना: SOAP कॉर्पोरेट अनुप्रयोगों के लिए एकदम सही है क्योंकि यह विकेंद्रीकृत, वितरित वातावरण में डेटा प्रवाह को सक्षम बनाता है और इसमें कई ऑनलाइन सुरक्षा सुविधाएँ शामिल हैं।
- अंतर्निहित परत के रूप में HTTP के अलावा किसी अन्य ट्रांसपोर्ट प्रोटोकॉल का उपयोग करना: SOAP अंतर्निहित परत के रूप में HTTP पर निर्भर नहीं है। आपके एप्लिकेशन के आधार पर, आप SMTP (सिंपल मेल ट्रांसफर प्रोटोकॉल), JMS (जावा मैसेजिंग सर्विस), या किसी अन्य ट्रांसपोर्ट प्रोटोकॉल का उपयोग कर सकते हैं।
- स्टेटफुल ऑपरेशंस के साथ काम करना: REST API के अनुरोधों के विपरीत, SOAP API के अनुरोध स्टेटफुल होते हैं, जिसका अर्थ है कि सर्वर क्लाइंट के बारे में जानकारी सहेजता है और अनुरोधों या संचालन की श्रृंखला में इसका उपयोग करता है। भले ही यह अधिक सर्वर बैंडविड्थ और संसाधनों का उपयोग करता है, यह बैंक हस्तांतरण जैसी नियमित या लिंक की गई गतिविधियों को करने के लिए महत्वपूर्ण है।
निष्कर्ष
REST और SOAP API के बीच तुलना से यह स्पष्ट हो जाता है कि REST, SOAP से बेहतर है। फिर भी, ऐसी स्थितियाँ हैं जहाँ SOAP API की आवश्यकता होती है। कुछ उदाहरणों में, वेब सेवाएँ REST और SOAP API को मिलाकर बनाई जाती हैं।
इसलिए, उपयोग का मामला यह निर्धारित करेगा कि कौन सी एपीआई शैली सबसे अच्छा काम करेगी।
एक जवाब लिखें