रेस्ट एपीआई थ्योरी

पहला मॉड्यूल आपके साथ एक HTTP अनुरोध बनाने, उसे भेजने और प्रतिक्रिया प्राप्त करने के साथ समाप्त हुआ।

हम भविष्य में ऐसा कई बार करेंगे। हम तीसरे पक्ष के सर्वर को अनुरोध भेजेंगे। हम ऐसे आवेदन करेंगे जो स्वयं ऐसे अनुरोधों को स्वीकार करते हैं और एक प्रतिक्रिया लौटाते हैं। हम अनुरोधों को संसाधित करने के लिए जटिल तर्क तैयार करेंगे।

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

दूसरे मॉड्यूल में हम यही करेंगे। चलिए चलते हैं!

सामान्य सिद्धांत

आइए सिद्धांत से शुरू करते हैं।

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

एपीआई

एपीआई - एप्लीकेशन प्रोग्रामिंग इंटरफेस । यह उन तरीकों का विवरण है जिसमें क्लाइंट और सर्वर एक दूसरे के साथ संवाद कर सकते हैं। हम एपीआई दस्तावेज खोलते हैं और वहां से सीखते हैं कि सर्वर से आवश्यक डेटा कैसे प्राप्त करें।

हम हमेशा चाहते हैं कि यह बातचीत सरल और समझने योग्य हो। यह दोनों डेवलपर्स के लिए कार्य को सरल करता है (नई सेवा डिजाइन करते समय पहिया को फिर से शुरू करने की आवश्यकता नहीं है) और उपयोगकर्ता (एक सेवा सीखना बहुत आसान है यदि यह पहले से परिचित सेवाओं के समान सिद्धांत पर काम करता है)। और यहाँ यह एक नया शब्द याद रखने योग्य है - REST।

विश्राम

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

यह नियमों और आवश्यकताओं का कुछ कठोर सेट नहीं है। आरईएसटी किसी विशेष प्रोग्रामिंग भाषा के उपयोग के लिए बाध्य नहीं करता है, न ही यह सख्त दिशानिर्देशों के साथ हाथ बांधता है। REST को एक वास्तुशिल्प शैली कहा जाता है और यह 6 सिद्धांतों को परिभाषित करता है जिनका एक सिस्टम आर्किटेक्चर को पालन करना चाहिए।

तदनुसार, आरईएसटी के सिद्धांतों को ध्यान में रखते हुए विकसित एक एपीआई को आरईएसटी एपीआई कहा जाता है, और अनुप्रयोगों को स्वयं को रीस्टफुल कहा जाता है

हम ऐसे ही RESTful एप्लिकेशन बना रहे हैं, इसलिए यह उन सिद्धांतों पर चर्चा करने लायक है जिनका वे तुरंत पालन करेंगे।

आराम के सिद्धांत

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

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

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

वर्दी इंटरफ़ेस । सिद्धांत क्लाइंट-सर्वर इंटरैक्शन के एकल प्रारूप को परिभाषित करता है। सभी अनुरोधों की संरचना समान होनी चाहिए। डेटा को उसी रूप में भेजा जाना चाहिए, चाहे कोई भी अनुरोध करे।

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

मांग पर कोड (वैकल्पिक) । एकमात्र सिद्धांत जो अनिवार्य नहीं है। इसके अनुसार, क्लाइंट सर्वर से निष्पादन योग्य कोड (उदाहरण के लिए, स्क्रिप्ट) डाउनलोड करके अपनी कार्यक्षमता का विस्तार कर सकता है। इस मामले में, कोड केवल मांग पर निष्पादित किया जाना चाहिए।