बाकी सामग्री वार्तालाप और कैशिंग

Question

मुझे आश्चर्य है कि कैसे कैशिंग सामग्री बातचीत एपीआई के साथ काम करता है। चूंकि XML या JSON में एक संसाधन प्राप्त करने के लिए, यूआरआई उदाहरण के लिए, एक ही हो जाएगा:

http://example.com/bikes/mountain 

सेवा देता स्वीकार प्रकार हैडर के आधार पर JSON/XML। कैश कितने स्मार्ट हैं?

उदाहरण के लिए: इस का उपयोग करते हुए

• यदि एक ग्राहक का अनुरोध प्रकार स्वीकार एक्सएमएल वापस जाने के लिए।
• प्रतिक्रिया 1 मिनट के लिए वेब सर्वर द्वारा कैश किया गया है।
• दूसरा ग्राहक अनुरोधों एक ही संसाधन प्रकार स्वीकार करें का उपयोग कर JSON वापस जाने के लिए

कैशिंग जांच बिल्कुल स्वीकार करता/सामग्री प्रकार? या क्या परिणामस्वरूप जेएसओएन अनुरोधकर्ता को एक्सएमएल डेटा वापस मिल रहा है क्योंकि सर्वर ने कैश किया था? मुझे उम्मीद है कि यह कुछ स्पष्ट है कि इसकी पहले से ही देखभाल की जा रही है, अन्यथा, क्या यह यूआरआई में .xml/.json को शामिल करने के लिए एक बहुत बड़ा तर्क नहीं है?

मुझे लगता है कि मेरा प्रश्न मूल रूप से है, क्या मैं मानक कैशिंग तकनीकों का उपयोग करते हुए सामग्री बातचीत का सुरक्षित रूप से उपयोग कर सकता हूं?

Answer 1

डैरल सही है कि वर्री हेडर क्लाइंट को बताता है जो हेडर से अनुरोध करता है कि यह संसाधन के विभिन्न प्रतिनिधित्व प्राप्त करने के लिए भिन्न हो सकता है।

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

दो अनुरोध अलग-अलग मान भेजते हैं, इसलिए उन्हें हमेशा अलग से कैश किया जाना चाहिए।

जब आप वेरी हेडर में '*' के मान का उपयोग करते हैं, तो इसका मतलब है कि प्रतिक्रिया को कैश नहीं किया जाना चाहिए।

Answer 2

हां। RFC 2616

में भिन्न शीर्षलेख की मेरी सरल समझ में, कैश हेडर फ़ील्ड्स का उपयोग करेंगे जो कि अलग-अलग शीर्षलेखों में नामित हैंडल फ़ील्ड का उपयोग करेंगे, जो विशिष्ट रूप से कैश किए गए प्रतिनिधित्व की पहचान करते हैं।