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