कैशिंग गितब एपीआई कॉल

Question

मेरे पास एपीआई कॉल के कैशिंग से संबंधित एक सामान्य प्रश्न है, इस उदाहरण में गिथब एपीआई को कॉल किया गया है।

मान लें कि मेरे पास मेरे ऐप में एक पृष्ठ है जो रेपो के फ़ाइल नाम और रीडमे की सामग्री दिखाता है। इसका मतलब है कि इसे पुनर्प्राप्त करने के लिए मुझे कुछ एपीआई कॉल करना होगा।

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

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

मुझे कल्पना है कि मैं ऑब्जेक्ट-शा के साथ ऐसा कुछ कर सकता हूं, लेकिन अगर मुझे एपीआई को कॉल करने की ज़रूरत है, तो यह कैशिंग के उद्देश्य को हरा देता है।

आप इसके बारे में कैसे जाएंगे? मुझे पता है कि prose.io जैसी कोई सेवा अभी कैशिंग नहीं है, लेकिन अगर ऐसा होना चाहिए, तो दृष्टिकोण क्या होगा?

धन्यवाद

Answer 1

बस का उपयोग कर सकते हैं HTTPS संचय आपके उपयोग के मामले के लिए काफी अच्छा हो सकता है? HTTP कैशिंग का उद्देश्य केवल अनुरोध नहीं करने का एक तरीका प्रदान करने के लिए नहीं है यदि आपके पास पहले से ही एक नई प्रतिक्रिया है, बल्कि यह आपको तुरंत सत्यापित करने में सक्षम बनाता है कि आपके पास कैश में पहले से मौजूद प्रतिक्रिया मान्य है (सर्वर को पूरा करने के बिना अगर यह ताजा है तो प्रतिक्रिया फिर से करें)।

गिटहब एपीआई प्रतिक्रियाओं को देखते हुए, मैं देख सकता हूं कि गिटहब प्रासंगिक HTTP शीर्षलेख (ईटीएजी, अंतिम-संशोधित, कैश-कंट्रोल) को सही ढंग से सेट कर रहा है।

तो, आप बस एक जीईटी करते हैं, उदा। के लिए:

GET https://api.github.com/users/izuzak/repos 

और इस रिटर्न:

200 OK 
... 
ETag:"df739f00c5053d12ef3c625ad6b0fd08" 
Last-Modified:Thu, 14 Feb 2013 22:31:14 GMT 
... 

अगली बार - आप एक ही संसाधन के लिए एक मिलता है, लेकिन यह भी प्रासंगिक HTTPS संचय हेडर की आपूर्ति इतना है कि यह वास्तव में एक सशर्त प्राप्त है:

GET https://api.github.com/users/izuzak/repos 
... 
If-Modified-Since:Thu, 14 Feb 2013 22:31:14 GMT 
If-None-Match:"df739f00c5053d12ef3c625ad6b0fd08" 
... 

और लो और निहारना - सर्वर एक 304 संशोधित नहीं प्रतिक्रिया लौटाता और अपने HTTP ग्राहक अपने कैश से प्रतिक्रिया खींच लेंगे:

+०१२३५१६४१०६

304 Not Modified 

तो, गिटहब एपीआई HTTP कैशिंग सही करता है और आपको इसका उपयोग करना चाहिए। अनुमोदित, आपको एक HTTP क्लाइंट का उपयोग करना होगा जो HTTP कैशिंग का भी समर्थन करता है। सबसे अच्छी बात यह है कि अगर आपको 304 संशोधित प्रतिक्रिया नहीं मिलती है - गिटहब आपके शेष एपीआई कॉल कोटा को कम नहीं करता है। देखें: http://developer.github.com/v3/#conditional-requests

गिटहब एपीआई Cache-Control: private, max-age=60 हेडर भी सेट करता है, इसलिए आपके पास 60 सेकंड ताजगी है - जिसका मतलब है कि 60 सेकंड से कम किए गए उसी संसाधन के लिए अनुरोध सर्वर पर भी नहीं किए जाएंगे।

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