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