8.1 दूरस्थ एपीआई दृष्टिकोण
क्लाइंट-सर्वर आर्किटेक्चर बनाते समय सभी प्रोग्रामर एक ही गलती करते हैं। वे सर्वर से अनुरोधों को विधि कॉल के रूप में देखना शुरू करते हैं ।
आप सर्वर पर रिपोर्ट बनाने की प्रक्रिया शुरू करना चाहते हैं, क्यों न इसे एक अनुरोध भेजें जैसे:
http://server.com/startDocumentGeneration?params
और रिपोर्ट पूरी होने के बाद उसे कैसे डाउनलोड करें? ऐसा करने के लिए, हम एक और तरीका लिखेंगे:
http://server.com/getDocument
सर्वर HttpSession
हमारे दस्तावेज़ पर जानकारी संग्रहीत करता है, और जैसे ही दस्तावेज़ उत्पन्न होता है, सर्वर उसे वापस दे देगा।
महान दृष्टिकोण। या नहीं?
दृष्टिकोण वास्तव में भयानक है। बात यह है कि सर्वर को दस्तावेज़ संख्या याद रखनी चाहिए। दूसरे शब्दों में, नई विधि कॉल को ठीक से संसाधित करने के लिए, सर्वर को पिछली विधियों को कॉल करने के परिणामों को याद रखना चाहिए।
वेब पर यह एक बड़ी समस्या है। इंटरनेट गायब हो सकता है, ब्राउज़र बंद हो सकता है। पृष्ठ को पुनः लोड किया जा सकता है या किसी लिंक पर गलती से क्लिक किया जा सकता है, और इसी तरह। और सर्वर पिछले उपयोगकर्ता अनुरोधों से मेगाबाइट डेटा संग्रहीत करना जारी रखेगा ...
सर्वर के साथ आराम से काम करने के लिए, आप यह उम्मीद नहीं कर सकते कि आपके पास सर्वर के पिछले अनुरोधों का डेटा हमेशा हाथ में रहेगा।
फिर सर्वर के तरीकों को कैसे कॉल करें? सही उत्तर भयानक होगा: बिलकुल नहीं!
8.2 आराम दृष्टिकोण
प्रोग्रामर बुनियादी बातों पर वापस चले गए और याद किया कि प्रारंभ में अनुरोध में सर्वर पर फ़ाइल का पथ शामिल था:
http://server.com/path?params
और हमने इस दृष्टिकोण का अधिकतम उपयोग करने का निर्णय लिया।
अब सर्वर को डेटा के भंडार के रूप में माना जाता है जो एक पेड़ के रूप में बाहर दिखाई देता है ।
यदि आप सभी उपयोगकर्ताओं की सूची प्राप्त करना चाहते हैं, तो क्वेरी को कॉल करें:
http://server.com/users
यदि आप उपयोगकर्ता 113 पर डेटा प्राप्त करना चाहते हैं, तो क्वेरी चलाएँ:
http://server.com/users/113
और इसी तरह, सभी एक ही नस में।
एक बार फिर, सर्वर को डेटा के भंडार के रूप में देखा जाता है जो बाहर पेड़ के रूप में दिखाई देता है।
डेटा प्राप्त किया जा सकता है - GET अनुरोध , संशोधित - POST अनुरोध और हटाए गए - DELETE अनुरोध ।
8.3 कोई राज्य नहीं
क्लाइंट और सर्वर के बीच बातचीत के REST प्रोटोकॉल के लिए निम्नलिखित शर्त की आवश्यकता होती है: क्लाइंट से अनुरोधों के बीच की अवधि के दौरान, क्लाइंट की स्थिति के बारे में कोई जानकारी सर्वर पर संग्रहीत नहीं होती है।
क्लाइंट से सभी अनुरोधों को इस तरह तैयार किया जाना चाहिए कि सर्वर को हर बार अनुरोध को पूरा करने के लिए आवश्यक सभी जानकारी प्राप्त हो । सत्र स्थिति क्लाइंट पक्ष पर सहेजी जाती है।
ग्राहक अनुरोधों के प्रसंस्करण के दौरान, ग्राहक को संक्रमणकालीन स्थिति में माना जाता है। प्रत्येक व्यक्तिगत एप्लिकेशन स्थिति को लिंक द्वारा दर्शाया जाता है जिसे क्लाइंट द्वारा अगली बार हिट करने पर लागू किया जा सकता है।
8.4 इंटरफ़ेस एकरूपता
सर्वर से ऑब्जेक्ट पुनर्प्राप्त करने के लिए उपयोग किए जाने वाले सभी पथ मानकीकृत हैं। यह बहुत सुविधाजनक है, खासकर यदि आप अन्य REST सर्वर से डेटा प्राप्त कर रहे हैं।
सभी ऑब्जेक्ट इंटरफेस को तीन शर्तों का पालन करना चाहिए:
संसाधन पहचान
URI का उपयोग करके अनुरोधों में सभी संसाधनों की पहचान की जाती है। सर्वर के अंदर संसाधन क्लाइंट को लौटाए गए दृश्यों से अलग होते हैं। उदाहरण के लिए, एक सर्वर डेटाबेस से HTML, XML, या JSON के रूप में डेटा भेज सकता है, इनमें से कोई भी सर्वर के भीतर स्टोरेज प्रकार नहीं है।
एक दृश्य के माध्यम से संसाधनों में हेरफेर
यदि क्लाइंट मेटाडेटा सहित संसाधन का प्रतिनिधित्व संग्रहीत करता है, तो उसके पास सर्वर पर संसाधन को संशोधित करने या हटाने के लिए पर्याप्त जानकारी होती है।
"स्व-वर्णन" संदेश
प्रत्येक संदेश में इसे संभालने के तरीके को समझने के लिए पर्याप्त जानकारी होती है। उदाहरण के लिए, यदि आपको उपयोगकर्ता के बारे में जानकारी चाहिए, तो सर्वर आपको एक JSON ऑब्जेक्ट लौटाएगा, जहाँ नाम, पता फ़ील्ड होंगे।
ऐसी स्थिति नहीं होनी चाहिए जहां ग्राहक को यह जानने की आवश्यकता हो कि प्रतिक्रिया में पहला नंबर उम्र है, और दूसरा जन्म तिथि है।
8.5 कैशिंग
REST दृष्टिकोण मानता है कि HTTP प्रोटोकॉल के माध्यम से डेटा अनुरोध किए जाते हैं। इसलिए, GET अनुरोध को कॉल करके ऑब्जेक्ट प्राप्त किए जाते हैं। इसका मतलब है कि वे, GET अनुरोध के माध्यम से प्राप्त सभी संसाधनों की तरह, HTTP संसाधनों को कैशिंग करने के सभी नियमों के अधीन हैं।
अर्थात्, REST API के माध्यम से प्राप्त डेटा उसी तरह से कैश किया जाता है जैसे वेब सर्वर पर कोई स्थिर संसाधन। सुंदरता :)
GO TO FULL VERSION