नमस्ते! आज हम एक ऐसे विषय के बारे में जानेंगे जो बहुत ही रोचक है और सबसे महत्वपूर्ण बात यह है कि श्रम बाजार में उच्च मांग है: REST। हम REST के अपने अवलोकन को तीन भागों में विभाजित करेंगे:
पहले भाग में, हम REST के इतिहास को कवर करेंगे और उन सिद्धांतों का वर्णन करेंगे जिन पर REST आधारित है।
दूसरे में, हम विचार करेंगे कि HTTP प्रोटोकॉल के माध्यम से क्लाइंट और सर्वर के बीच संचार कैसे होता है।
तीसरे में, हम एक छोटा सा रेस्टफुल एप्लिकेशन लिखेंगे जिसे हम "पोस्टमैन" नामक प्रोग्राम का उपयोग करके परीक्षण करेंगे।
लेख निम्नलिखित शर्तों से परिचित पाठकों के लिए अभिप्रेत है:
एचटीटीपी
यूआरएल और यूआरआई
JSON और (कुछ हद तक) XML
डिपेंडेंसी इंजेक्शन
भाग 1. आराम क्या है?
REST, जैसे IT दुनिया में बहुत कुछ है, एक संक्षिप्त नाम है। यह "प्रतिनिधि राज्य स्थानांतरण" से लिया गया है । यह एक कंप्यूटर नेटवर्क में वितरित सिस्टम के घटकों के बीच बातचीत के लिए एक वास्तुशिल्प शैली है। सीधे शब्दों में कहें, REST सिस्टम के विभिन्न घटकों के बीच बातचीत (डेटा का आदान-प्रदान) के लिए शैली निर्धारित करता है, जिनमें से प्रत्येक भौतिक रूप से अलग-अलग स्थानों पर स्थित हो सकता है। यह स्थापत्य शैली एक वितरित प्रणाली को डिजाइन करते समय पालन की जाने वाली बाधाओं का एक सुसंगत सेट है। इन बाधाओं को कभी-कभी REST का मार्गदर्शक सिद्धांत कहा जाता है। बहुत सारे नहीं हैं, केवल 6 हैं। हम उनके बारे में थोड़ी देर बाद बात करेंगे।
REST सिद्धांतों को ध्यान में रखकर बनाए गए एप्लिकेशन, यानी जो REST बाधाओं का उल्लंघन नहीं करते हैं, उन्हें "RESTful" कहा जाता है।
आराम का इतिहास
REST शब्द को HTTP प्रोटोकॉल के रचनाकारों में से एक, रॉय फील्डिंग ने अपनी पीएच.डी. में पेश किया था। 2000 में "आर्किटेक्चरल स्टाइल्स एंड द डिज़ाइन ऑफ़ नेटवर्क-बेस्ड सॉफ़्टवेयर आर्किटेक्चर" नामक थीसिस। हालांकि REST शब्द को अभी भी युवा कहा जा सकता है, यह जिस अवधारणा का प्रतिनिधित्व करता है वह वर्ल्ड वाइड वेब के मूल में निहित है। हम शब्द के इतिहास में गहराई से गोता नहीं लगाएंगे। यदि आप प्राथमिक स्रोतों में गोता लगाना चाहते हैं, तो फील्डिंग के शोध प्रबंध पर एक नज़र डालें ।
बाकी बाधाओं और सिद्धांतों
जैसा कि ऊपर कहा गया है, REST परिभाषित करता है कि वितरित सिस्टम के घटकों को एक दूसरे के साथ कैसे इंटरैक्ट करना चाहिए। सामान्य तौर पर, यह अनुरोध-प्रतिक्रिया प्रक्रिया के माध्यम से होता है। अनुरोध भेजने वाले घटक को क्लाइंट कहा जाता है , और अनुरोध को संसाधित करने और क्लाइंट को प्रतिक्रिया भेजने वाले घटक को सर्वर कहा जाता है।. अनुरोध और प्रतिक्रियाएँ अक्सर HTTP प्रोटोकॉल के माध्यम से भेजी जाती हैं। HTTP का मतलब हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल है। आमतौर पर, एक सर्वर कुछ वेब एप्लिकेशन होता है। ग्राहक लगभग कुछ भी हो सकता है। उदाहरण के लिए, एक मोबाइल ऐप जो सर्वर से डेटा का अनुरोध करता है। या एक ब्राउज़र जो डेटा डाउनलोड करने के लिए वेब पेज से सर्वर को अनुरोध भेजता है। एप्लिकेशन A, एप्लिकेशन B से डेटा का अनुरोध कर सकता है। इस मामले में, A, B के संबंध में एक क्लाइंट है, और B, A के संबंध में एक सर्वर है। उसी समय, A, B, C, D, आदि से अनुरोधों को संसाधित कर सकता है। इस स्थिति में, एप्लिकेशन A सर्वर और क्लाइंट दोनों है। सब कुछ संदर्भ पर निर्भर करता है। एक बात निश्चित है: अनुरोध भेजने वाला घटक ग्राहक है। अनुरोध प्राप्त करने, संसाधित करने और प्रतिक्रिया देने वाला घटक सर्वर है। हालाँकि, प्रत्येक प्रणाली जिसके घटक अनुरोध-प्रतिक्रिया प्रक्रिया के माध्यम से संचार करते हैं, एक विश्वसनीय प्रणाली नहीं है। किसी सिस्टम को रेस्टफुल माने जाने के लिए, उसे छह REST बाधाओं का पालन करना चाहिए:
1. क्लाइंट-सर्वर आर्किटेक्चर
यह बाधा चिंताओं को अलग करने के बारे में है। क्लाइंट इंटरफ़ेस की आवश्यकताओं को डेटा संग्रहीत करने वाले सर्वर की आवश्यकताओं से अलग करना आवश्यक है। यह बाधा क्लाइंट कोड को अन्य प्लेटफॉर्म के लिए अधिक पोर्टेबल बनाती है, और सर्वर साइड को सरल बनाने से सिस्टम की मापनीयता में सुधार होता है। "क्लाइंट" और "सर्वर" के बीच अंतर करना उन्हें एक दूसरे से स्वतंत्र रूप से विकसित करने की अनुमति देता है।
2. स्टेटलेस
एक विश्वसनीय वास्तुकला के लिए निम्नलिखित शर्तों को पूरा करने की आवश्यकता होती है। अनुरोधों के बीच की अवधि में, सर्वर को ग्राहक की स्थिति और इसके विपरीत के बारे में जानकारी संग्रहीत नहीं करनी चाहिए। क्लाइंट से सभी अनुरोधों को इस तरह से तैयार किया जाना चाहिए जिससे सर्वर को अनुरोध को पूरा करने के लिए सभी आवश्यक जानकारी मिल सके। इस प्रकार, सर्वर और क्लाइंट दोनों पिछले संदेशों पर भरोसा किए बिना किसी भी प्राप्त संदेश को "समझ" सकते हैं।
3. साध्य
ग्राहक सर्वर प्रतिक्रियाओं को कैश कर सकते हैं। बदले में, इन्हें स्पष्ट रूप से या अप्रत्यक्ष रूप से कैश्ड या नॉन-कैश के रूप में निर्दिष्ट किया जाना चाहिए, ताकि क्लाइंट को बाद के अनुरोधों के जवाब में पुराना या गलत डेटा प्राप्त न हो। सही कैशिंग कुछ क्लाइंट-सर्वर इंटरैक्शन को पूरी तरह या आंशिक रूप से समाप्त करने में मदद करता है, सिस्टम प्रदर्शन और स्केलेबिलिटी को और बढ़ाता है।
4. समान इंटरफ़ेस
रेस्टफुल आर्किटेक्चर की मूलभूत आवश्यकताओं में एक एकीकृत, समान इंटरफ़ेस शामिल है। ग्राहक को अनुरोध भेजते समय उपयोग किए जाने वाले प्रारूप और पतों को हमेशा समझना चाहिए, और बदले में सर्वर को उस प्रारूप को भी समझना चाहिए जिसका उपयोग क्लाइंट अनुरोधों का जवाब देते समय करना चाहिए। यह सुसंगत क्लाइंट-सर्वर इंटरैक्शन जो वर्णन करता है कि क्या, कहाँ, किस रूप में, और डेटा कैसे भेजा जाए, एक एकीकृत इंटरफ़ेस है।
5. परतें
परतों से हमारा तात्पर्य नेटवर्क की श्रेणीबद्ध संरचना से है। कभी-कभी क्लाइंट सीधे सर्वर से संवाद कर सकता है, और कभी-कभी यह केवल मध्यवर्ती नोड के साथ संचार करता है। भार संतुलन और वितरित कैशिंग के कारण मध्यवर्ती सर्वरों का उपयोग स्केलेबिलिटी को बढ़ा सकता है। आइए एक उदाहरण दें। एक मोबाइल ऐप की कल्पना करें जो पूरी दुनिया में लोकप्रिय है। ऐप के एक अभिन्न अंग में चित्रों को लोड करना शामिल है। इसके उपयोगकर्ताओं की संख्या लाखों में है, इसलिए एक अकेला सर्वर इतना भारी भार नहीं संभाल सकता है। सिस्टम को परतों में अलग करने से यह समस्या हल हो जाएगी। यदि क्लाइंट एक मध्यवर्ती नोड से चित्र का अनुरोध करता है, तो मध्यवर्ती नोड उस सर्वर से चित्र का अनुरोध करता है जो इस समय कम से कम लोड होता है और क्लाइंट को चित्र लौटाता है। यदि कैशिंग को पदानुक्रम के प्रत्येक स्तर पर सही ढंग से लागू किया जाता है,
6. कोड ऑन डिमांड (वैकल्पिक)
इस बाधा का अर्थ है कि क्लाइंट एप्लेट्स या स्क्रिप्ट के रूप में सर्वर से कोड डाउनलोड करके अपनी कार्यक्षमता का विस्तार कर सकता है।
एक विश्वसनीय वास्तुकला के लाभ
उपरोक्त सभी बाधाओं का अनुपालन करने वाले अनुप्रयोगों के निम्नलिखित फायदे हैं: विश्वसनीयता (ग्राहक की स्थिति को बचाने की कोई आवश्यकता नहीं है, जो खो सकती है)
प्रदर्शन (कैश के उपयोग के कारण)
scalability
पारदर्शी संचार
सरल इंटरफेस
सुवाह्यता
आसानी से परिवर्तन करने की क्षमता
नई आवश्यकताओं को विकसित करने और अनुकूलित करने की क्षमता
हम REST के अपने अवलोकन को तीन भागों में विभाजित करेंगे:
