सर्वर के लिए RESTful API - इसे सही करना (भाग 2)

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

HTTP API, REST और HATEOAS

वर्तमान में, HTTP एपीआई में विभाजित किया जा सकता है

• वेब सेवाएँ
• आरपीसी यूआरआई टनलिंग
• HTTP- आधारित टाइप 1
• HTTP- आधारित टाइप 2
• बाकी

यहाँ जॉन Algermissen से इसके लिए एक बहुत अच्छी व्याख्या है । दुर्भाग्यवश, कोई भी व्यक्ति जो एपीआई प्रदान करता है, अपनी RESTful सेवा को कॉल करता है, भले ही वह ऐसा न हो।
तो असली असली सर्वर क्या है? यह किसी भी हाइपरटेक्स्ट / हाइपरमीडिया आधारित एपीआई है। दूसरे शब्दों में, एक तृतीय-पक्ष डेवलपर या क्लाइंट एप्लिकेशन रूट API URL के माध्यम से "अन्य उपलब्ध संसाधनों" के बारे में जानकारी प्राप्त करने में सक्षम होना चाहिए। Restful API को कार्यान्वित करते समय यह वास्तव में सबसे महत्वपूर्ण स्थिति है। इसके अलावा, केवल एक जो HATEOAS सिद्धांत का पालन करता है, उसे वास्तविक RESTful सर्वर माना जा सकता है।

HATEOAS - हाइपरमीडिया अनुप्रयोग राज्य के इंजन के रूप में

HATEOAS को लागू करते समय दो मुख्य सिद्धांतों का पालन किया जाना चाहिए:

1. सेवा केवल हाइपरमीडिया संसाधन। हाइपरलिंक संसाधन वे होते हैं जिनमें केवल सामग्री होती है और अन्य हाइपरलिंक संसाधनों के लिए हाइपरलिंक। JSON (एप्लिकेशन / json) हाइपरलिंक संसाधन नहीं है। (दूसरी ओर, कई RESTful, HATEOAS सर्वर हैं जो JSON का समर्थन करते हैं) हालांकि, आप JSON में अतिरिक्त फ़ील्ड जोड़ सकते हैं, जिससे यह हाइपरलिंक संसाधन के रूप में कार्य कर सकता है। (उदाहरण के लिए: संबंधित छवि थंबनेल के लिंक के लिए href फ़ील्ड)
2. ग्राहक आवेदन के लिए एकल प्रवेश बिंदु। API होमपेज से, बाद में GET कॉल को संबंधित URL के लिंक के रूप में और बाद में "POST", "PUT" या "DELETE" अनुरोध फॉर्म के रूप में किए जाने चाहिए।

इन दो HATEOAS सिद्धांतों का पालन करने से आपको जो मुख्य लाभ मिलता है, वह है प्रलेखन में आसानी।

क्या आप अपने नए API में HATEOAS का उपयोग करते हैं?

नहीं!
क्यों? अतीत में, एपीआई ज्यादातर वेब अनुप्रयोगों में उपयोग के लिए लिखे गए थे। ये सर्वर आमतौर पर एक्सएचटीएमएल लौटाते हैं, और क्लाइंट एप्लिकेशन ब्राउज़र में चलते हैं। ऐसी योजना का ब्राउज़र आपके मोबाइल क्लाइंट के समान है, जो हाइपरलिंक संसाधनों को पार्स करता है, यह जानता है कि प्रपत्र क्या है और इसे उपयोगकर्ता को कैसे प्रस्तुत करना है। मोबाइल एप्लिकेशन के मामले में, जब आपके RESTful सर्वर की प्रतिक्रिया में एक फॉर्म होता है, जिसमें से आप सर्वर को डेटा भेज सकते हैं, तो आप (कम से कम बिना अतिरिक्त प्रयास के) उसे प्लेटफ़ॉर्म पर उपलब्ध देशी इंटरफ़ेस तत्वों में परिवर्तित नहीं कर सकते। प्लेटफ़ॉर्म प्रदाताओं में से कोई भी, Apple / Google या Microsoft, XHTML फ़ॉर्म को UIViewController (iOS पर) या इरादे (Android पर) या सिल्वरलाइट पेज (विंडोज फोन पर) में बदलने के लिए समर्थन प्रदान करता है। मैं GET अनुरोधों के जवाब में हाइपरलिंक संसाधनों के आउटपुट का उपयोग करने और सभी POST / PUT और DELETE अनुरोधों के लिए नियंत्रक विधियों (प्रपत्रों के बजाय) को कॉल करने की सलाह देता हूं। (उदाहरण के लिए: / दोस्तों / जोड़ने या / स्थानों / चेकिन) नियंत्रक विधियों को कॉल अन्य उत्तरों में एम्बेड किया जा सकता है (ताकि क्लाइंट एप्लिकेशन या डेवलपर उनके बारे में पता लगा सकें)। बेशक यह REST के सिद्धांतों का उल्लंघन करता है, लेकिन यह ठीक है। बेहतर गुणवत्ता वाले उत्पाद बनाने की तुलना में बेहतर तरीके से मानकों का पालन करना जो व्यवहार में कम उपयोग के हैं। (यह संभवतः हमारे एपीआई को HTTP- आधारित टाइप 2 बनने का कारण बनेगा)।

कैशिंग

हम कैशिंग करने के लिए पास। कैशिंग, जैसा कि कई लोग मानते हैं, मूल रूप से एक क्लाइंट कार्य (या एक मध्यवर्ती प्रॉक्सी कार्य) है। लेकिन आप जानते हैं कि, सर्वर साइड को विकसित करने में बहुत कम प्रयास के साथ, आप अपने एपीआई को पूरी तरह से मध्यवर्ती कैशिंग प्रॉक्सी की आवश्यकताओं को पूरा कर सकते हैं? इसका मतलब है कि आपको उनके हिस्से पर मुफ्त भार संतुलन प्राप्त होगा। आपको केवल HTTP विनिर्देश के 13 वें अध्याय में वर्णित किया गया है।

बहुत पहले नहीं, कला टेलर ने ट्वीट किया:

"मैं दो नए नियमों के साथ आया हूं: 1) यदि आपका आवेदन धीमा हो जाता है, तो कैशिंग जोड़ें। 2) यदि आवेदन छोटी गाड़ी है, तो कैशिंग को हटा दें। खैर, कैशिंग इतना मुश्किल क्यों है!"

लेकिन मेरा विश्वास करो, ऐसी समस्याओं का सामना किए बिना कैशिंग को लागू किया जा सकता है। मेरे द्वारा सुझाए गए दो मुख्य सिद्धांत हैं:

1. कस्टम अनुप्रयोग में कस्टम कैशिंग योजनाएँ बनाने का प्रयास न करें।
2. RFC HTTP 1.1 विनिर्देशन में वर्णित मूल कैशिंग सिद्धांतों को समझें। दो कैशिंग मॉडल वहां वर्णित हैं। वैधता मॉडल और वैधता मॉडल।

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

समाप्ति मॉडल

आइए एक सामान्य कैशिंग कॉन्फ़िगरेशन को देखें। यदि आप nginx का उपयोग करते हैं, तो संभवतः आपके पास कुछ समान है:

location ~ \.(jpg|gif|png|ico|jpeg|css|swf)$ { expires 7d; } 

nginx इन सेटिंग्स को उपयुक्त HTTP हेडर में तब्दील करता है। इस स्थिति में, सर्वर सभी छवियों के लिए हेडर में "एक्सपायर" या "कैश-कंट्रोल: मैक्स-एज = एन" फ़ील्ड भेजता है और क्लाइंट से 7 दिनों के लिए उन्हें कैश करने की अपेक्षा करता है। इसका मतलब है कि आपको अगले 7 दिनों के लिए समान डेटा का अनुरोध करने की आवश्यकता नहीं होगी। प्रत्येक सामान्य ब्राउज़र (और मध्यवर्ती प्रॉक्सी) इस हेडर का सम्मान करता है और उम्मीद के मुताबिक काम करता है। दुर्भाग्य से, लोकप्रिय SDWebImage सहित iOS के लिए अधिकांश ओपन सोर्स इमेज कैशिंग फ्रेमवर्क, एक अंतर्निहित कैशिंग तंत्र का उपयोग करते हैं जो केवल n दिनों के बाद छवियों को हटा देता है। समस्या यह है कि इस तरह के ढांचे वैधता मॉडल के अनुरूप नहीं हैं और इन रूपरेखाओं का उपयोग करने वाला आपका क्लाइंट एप्लिकेशन गैर-मानक समाधान (हैक्स) का सहारा लेने के लिए मजबूर है। मैं एक उदाहरण दूंगा कि यहां क्या गलत हो सकता है। चलो हमारे "नए फेसबुक" पर वापस आते हैं। जब आपका उपयोगकर्ता सर्वर पर एक अवतार अपलोड करता है, तो वह मानता है कि परिवर्तन सभी दृश्यों में दिखाई देंगे। कुछ ट्रिकी डेवलपर्स एक सफल अपडेट-प्रोफ़ाइल-छवि कॉल के बाद स्थानीय कैश को साफ़ करते हैं। (इसका मतलब है कि सभी नियंत्रकों को सर्वर से नए तरीके से चित्र डाउनलोड करना होगा)। सब कुछ बढ़िया काम करता है, आपने प्रोजेक्ट मैनेजर को सूचित किया और प्रत्येक दृश्य में अब नवीनतम प्रोफ़ाइल चित्र प्रदर्शित किया गया है। हालाँकि, यह समस्या को पूरी तरह से हल नहीं करता है। उसके दोस्त केवल 7 दिनों के बाद उपयोगकर्ता का नया अवतार देखेंगे। बिल्कुल अस्वीकार्य। तो इसे कैसे हल करें? जैसा कि मैंने कहा, आपको इस कथन को स्वीकार करना चाहिए कि केवल एक सर्वर विश्वसनीय डेटा का स्रोत हो सकता है। समय से पहले कैश की गई सामग्री को समाप्त करके कैश को अपडेट करने के लिए क्लाइंट पर बेईमान चाल का उपयोग न करें।

वैधता मॉडल

फेसबुक और ट्विटर दोनों ही पुरानी प्रोफ़ाइल छवियों की समस्या को हल करते हैं (एक नई छवि अपलोड होने के बाद) वैधता मॉडल का उपयोग करते हुए। वैधता मॉडल में, सर्वर क्लाइंट के लिए एक अद्वितीय संसाधन पहचानकर्ता भेजता है और ग्राहक पहचानकर्ता और प्रतिक्रिया दोनों को कैश करता है। HTTP के संदर्भ में, इस विशिष्ट पहचानकर्ता को ETag कहा जाता है। जब आप एक ही संसाधन के लिए दूसरा अनुरोध करते हैं, तो आपको इसे ETag पर भेजना होगा। सर्वर इस पहचानकर्ता का उपयोग यह जांचने के लिए करता है कि आपके द्वारा अनुरोधित संसाधन अंतिम कॉल के बाद से बदल दिया गया है (याद रखें, सर्वर एकमात्र विश्वसनीय स्रोत है)। यदि संसाधन वास्तव में बदल गया है, तो यह अंतिम प्रतिलिपि भेजता है। अन्यथा, यह 304 Not Modified भेजता है। कैश वैधता मॉडल को कैश को लागू करने के लिए क्लाइंट और सर्वर दोनों हिस्सों को लागू करने के लिए डेवलपर से अतिरिक्त प्रयासों की आवश्यकता होती है। मैं उन दोनों का आगे वर्णन करूंगा।

ग्राहक सहायता

वास्तव में iOS के तहत, यदि आप MKNetworkKit का उपयोग करते हैं तो यह सभी काम स्वचालित रूप से करता है। लेकिन एंड्रॉइड और विंडोज फोन के लिए डेवलपर्स के लिए, मैं विस्तार से वर्णन करूंगा कि इसे कैसे लागू किया जाना चाहिए।
कैश वैधता मॉडल ETag और अंतिम-संशोधित HTTP हेडर का उपयोग करता है। क्लाइंट साइड को लागू करना सर्वर साइड की तुलना में आसान है। यदि आपको एक संसाधन के साथ ETag प्राप्त हुआ है, जब आप इसे प्राप्त करने के लिए दूसरा अनुरोध करते हैं, तो हेडर के "IF-NONE-MATCH" फ़ील्ड में एक ETag भेजें। इसी तरह, यदि आपको किसी संसाधन के साथ "अंतिम-संशोधित" प्राप्त हुआ है, तो उसे बाद के अनुरोधों में "IF-MODOFIED-SINCE" हेडर पर भेजें। सर्वर, इसके भाग के लिए, "ETag" का उपयोग करने के लिए, और जब "अंतिम-संशोधित" का फैसला करेगा।



समाप्ति मॉडल का कार्यान्वयन सरल है। हेडर फ़ील्ड्स, "एक्सपायर" या "कैश-कंट्रोल: मैक्स-एज-एन" के आधार पर समाप्ति तिथि की गणना करें और इस तिथि तक पहुंचने पर कैश को साफ़ करें।

सर्वर साइड कार्यान्वयन

ETag का उपयोग करना
ETag आमतौर पर हैश एल्गोरिदम का उपयोग कर एक सर्वर पर गणना की जाती है। (अधिकांश उच्च-स्तरीय सर्वर भाषाओं जैसे जावा / सी # / स्काला में हैशिंग ऑब्जेक्ट्स के लिए सुविधाएं हैं)। प्रतिक्रिया उत्पन्न करने से पहले, सर्वर को ऑब्जेक्ट के हैश की गणना करनी चाहिए और इसे ETag हेडर फ़ील्ड में जोड़ना होगा। अब, यदि ग्राहक ने वास्तव में अनुरोध में एक IF-NONE-MATCH भेजा है और यह ETag आपके द्वारा गणना किए गए के बराबर है, तो 304 Not Modified भेजें। अन्यथा, एक प्रतिक्रिया बनाएं और इसे नए ईटैग के साथ भेजें।

अंतिम-संशोधित का उपयोग करना
अंतिम-संशोधित के उपयोग को लागू करना पूरी तरह से सीधा नहीं है। आइए कल्पना करें कि हमारे एपीआई में एक कॉल है जो दोस्तों की एक सूची देता है।

 http://api.mynextfacebook.com/friends/ 

जब आप ETag का उपयोग करते हैं, तो आप दोस्तों की एक सरणी के हैश की गणना करते हैं। अंतिम-संशोधित का उपयोग करते समय, आपको उस तारीख को भेजना होगा जिसे संसाधन अंतिम रूप से संशोधित किया गया था। चूंकि यह संसाधन एक सूची है, इसलिए यह तिथि आपके द्वारा अंतिम बार एक नया मित्र जोड़ने की तिथि होनी चाहिए। इसके लिए डेवलपर को डेटाबेस में प्रत्येक उपयोगकर्ता के लिए अंतिम डेटा परिवर्तन की तारीख को व्यवस्थित करने की आवश्यकता होती है। ETag से थोड़ा अधिक जटिल है, लेकिन यह प्रदर्शन के मामले में एक बड़ा लाभ देता है।
जब कोई ग्राहक पहली बार किसी संसाधन का अनुरोध करता है, तो आप दोस्तों की पूरी सूची भेजते हैं। क्लाइंट से बाद में किए गए अनुरोधों में हेडर में "IF-MODIFIED-SINCE" फ़ील्ड होगा। आपके सर्वर कोड को निर्दिष्ट तिथि के बाद जोड़े गए मित्रों की सूची भेजनी चाहिए। संशोधन से पहले डेटाबेस तक पहुँचने का कोड कुछ इस प्रकार था:

 SELECT * FROM Friends; 

संशोधन के बाद यह इस तरह बन गया:

 SELECT * FROM Friends WHERE friendedDate > IF-MODIFIED-SINCE; 

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

एक कैशिंग मॉडल चुनना

So. यह एक कठिन विषय था। अब मैं किसी विशेष कैशिंग मॉडल का उपयोग करने के लिए बुनियादी नियमों को संक्षेप और व्युत्पन्न करने की कोशिश करूँगा।

1. सभी अभी भी छवियों को समाप्ति मॉडल द्वारा सेवा दी जानी चाहिए।
2. गतिशील रूप से उत्पन्न सभी डेटा को वैधता मॉडल द्वारा कैश किया जाना चाहिए।
3. यदि आपका गतिशील रूप से उत्पन्न संसाधन एक सूची है, तो आपको अंतिम-संशोधित वैधता मॉडल का उपयोग करना चाहिए। (जैसे / दोस्त)। अन्य मामलों में, एक ETag- आधारित वैधता मॉडल का उपयोग किया जाना चाहिए। (जैसे / गर्लफ्रेंड/firstname.lastname)।
4. छवियाँ या कोई अन्य संसाधन जिन्हें उपयोगकर्ता द्वारा संशोधित किया जा सकता है (जैसे कि एक अवतार) भी ETag का उपयोग करके वैधता मॉडल द्वारा कैश किया जाना चाहिए। हालांकि ये छवियां हैं, वे स्थायी नहीं हैं, जैसे कि कंपनी का लोगो। इसके अतिरिक्त, आप ऐसे संसाधनों की वैधता अवधि की सही गणना नहीं कर सकते हैं।

एक और तरीका (लागू करने में आसान है, लेकिन थोड़ा हैकी) "URL त्रुटि" का उपयोग करना है। जब उत्तर में एक अवतार URL होता है, तो आपको इसका हिस्सा गतिशील बनाने की आवश्यकता होती है। इसलिए के रूप में URL का प्रतिनिधित्व करने के बजाय

 http://images.mynextfacebook.com/person/firstname.lastname/avatar 

करने के लिए

 http://images.mynextfacebook.com/person/firstname.lastname/avatar/<> 

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

इस लेख में, मैंने मानकों का एक सरल विवरण दिया, जो कि अधिकांश डेवलपर्स का पालन नहीं करते हैं।

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

मैं पढ़ने की सलाह देता हूं

बाकी एपीआई डिजाइन नियम पुस्तिका