आपको Apigee Edge दस्तावेज़ दिख रहा है.
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
इस पेज पर जाएं
Apigee X दस्तावेज़. जानकारी

यह बैकएंड संसाधन का डेटा कैश मेमोरी में सेव करता है. इससे संसाधन के अनुरोधों की संख्या कम हो जाती है. ऐप्लिकेशन के तौर पर एक ही यूआरआई को अनुरोध भेजें, तो आप इसके बजाय कैश मेमोरी में सेव किए गए जवाबों को वापस लौटाने के लिए इस नीति का इस्तेमाल कर सकते हैं को उन अनुरोधों को बैकएंड सर्वर पर भेजना होगा. प्रतिक्रिया कैश नीति आपके एपीआई की नेटवर्क ट्रैफ़िक और इंतज़ार के समय में कमी की वजह से परफ़ॉर्मेंस.
आपके एपीआई में इस्तेमाल किया जाने वाला बैकएंड डेटा अपडेट होने पर, आपको Responseकैश ज़्यादा मदद मिल सकती है समय-समय पर. उदाहरण के लिए, मान लें कि आपके पास एक ऐसा एपीआई है जो मौसम की रिपोर्ट का डेटा दिखाता है और हर 10 मिनट में रीफ़्रेश होता है. जवाब देने के लिए कैश मेमोरी का इस्तेमाल करके, कैश मेमोरी में सेव किए गए जवाबों को इन दोनों के बीच में वापस पाया जा सकता है रीफ़्रेश होने के बाद, बैकएंड तक पहुंचने के अनुरोधों की संख्या कम की जा सकती है. इससे यह भी कम होता है कि नेटवर्क हॉप की संख्या.
सामान्य काम के लिए कम समय तक कैश मेमोरी में डेटा सेव करने के लिए, कैश मेमोरी भरने से जुड़ी नीति का इस्तेमाल करें. उस नीति का इस्तेमाल कैश मेमोरी में बदलाव करने की नीति (कैश एंट्री पढ़ने के लिए) और कैश मेमोरी में सेव डेटा को अमान्य करने से जुड़ी नीति (अमान्य एंट्री के लिए).
रिस्पॉन्स कैश की नीति के बारे में जानने के लिए, यह वीडियो देखें.
सैंपल
10 मिनट की कैश मेमोरी
यह सैंपल दिखाता है कि कैश मेमोरी में सेव किए गए जवाबों को 10 मिनट.
मान लें कि आपके पास नीचे दिए गए यूआरएल पर एक एपीआई है:
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
क्वेरी पैरामीटर w
का इस्तेमाल कैश मेमोरी के तौर पर किया जा रहा है. Apigee Edge
अनुरोध मिलने पर, क्वेरी पैरामीटर w
की वैल्यू. अगर मान्य हो (वह
है, जिसकी समयसीमा खत्म नहीं हुई है) रिस्पॉन्स, कैश मेमोरी में मौजूद है, तो कैश मेमोरी में सेव किया गया रिस्पॉन्स मैसेज है
अनुरोध करने वाले क्लाइंट को वापस भेज दिया गया है.
अब मान लें कि आपने Responseकैश नीति को इस तरह से कॉन्फ़िगर किया है.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
जब एपीआई प्रॉक्सी को नीचे दिए गए यूआरएल के लिए अनुरोध का मैसेज मिलता है, तो रिस्पॉन्स को कैश मेमोरी में सेव किया जाता है. 10 मिनट के भीतर दूसरे अनुरोध पर, एक कैशे लुकअप होता है -- कैश मेमोरी में सेव किया गया जवाब, ऐप्लिकेशन में लौटाया जाता है. इसमें बैकएंड सेवा को कोई अनुरोध नहीं भेजा जाता.
http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778
कैश मेमोरी खोजना छोड़ें
नीचे दिया गया उदाहरण दिखाता है कि कैश लुकअप को कैसे छोड़ा जाए और कैश मेमोरी कैसे सेव की जाए रीफ़्रेश किया गया. यह भी देखें यह वीडियो स्किप करने के तरीके का इस्तेमाल करने के बारे में है.
स्किप कैश लुकअप की वैकल्पिक शर्त (अगर कॉन्फ़िगर की गई है) का आकलन अनुरोध के पाथ में किया जाता है. अगर स्थिति का आकलन सही लगता है, तो कैश मेमोरी लुक अप को छोड़ दिया जाता है और कैश मेमोरी को रीफ़्रेश किया गया.
कंडीशनल कैश मेमोरी को रीफ़्रेश करने की सुविधा का सामान्य इस्तेमाल एक ऐसी शर्त है जो किसी खास एचटीटीपी को तय करती है हेडर, जिसकी वजह से शर्त का आकलन सही के तौर पर होता है. स्क्रिप्ट किया गया क्लाइंट ऐप्लिकेशन यह हो सकता है इसे समय-समय पर सही एचटीटीपी हेडर के साथ अनुरोध सबमिट करने के लिए कॉन्फ़िगर किया गया है. जिससे रिस्पॉन्स कैश मेमोरी रीफ़्रेश हो रही है.
उदाहरण के लिए, नीचे दिए गए यूआरएल पर किसी एपीआई को कॉल करने की कल्पना करें:
'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"
अब उस प्रॉक्सी पर कॉन्फ़िगर की गई नीचे दी गई प्रतिक्रिया कैश नीति की कल्पना करें. ध्यान दें कि बायपास-कैश कंडिशन 'सही' पर सेट है.
<ResponseCache name="ResponseCache"> <CacheKey> <KeyFragment ref="request.queryparam.w" /> </CacheKey> <!-- Explicitly refresh the cached response --> <SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup> <ExpirySettings> <TimeoutInSeconds>600</TimeoutInSeconds> </ExpirySettings> </ResponseCache>
शर्तों के बारे में ज़्यादा जानकारी के लिए, फ़्लो वैरिएबल और शर्तें.
एलिमेंट का रेफ़रंस
एलिमेंट के रेफ़रंस में, नीति के एलिमेंट और एट्रिब्यूट के बारे में बताया जाता है.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1"> <DisplayName>Response Cache 1</DisplayName> <Properties/> <CacheKey> <Prefix/> <KeyFragment ref="request.uri" /> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <ExpiryDate/> <TimeOfDay/> <TimeoutInSeconds ref="flow.variable.here">300</TimeoutInSeconds> </ExpirySettings> <CacheResource>cache_to_use</CacheResource> <CacheLookupTimeoutInSeconds/> <ExcludeErrorResponse/> <SkipCacheLookup/> <SkipCachePopulation/> <UseAcceptHeader/> <UseResponseCacheHeaders/> </ResponseCache>
<ResponseCache> एट्रिब्यूट
<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">
यहां दी गई टेबल में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट में एक जैसे होते हैं:
एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी |
---|---|---|---|
name |
नीति का अंदरूनी नाम. इसके अलावा, नीति को लेबल करने के लिए, |
लागू नहीं | ज़रूरी है |
continueOnError |
किसी नीति के काम न करने पर, गड़बड़ी दिखाने के लिए नीति के लागू होने के बाद भी फ़्लो को एक्ज़ीक्यूट करने के लिए, इसे |
गलत | वैकल्पिक |
enabled |
नीति को लागू करने के लिए, नीति को बंद करने के लिए, |
सही | वैकल्पिक |
async |
यह एट्रिब्यूट अब काम नहीं करता. |
गलत | बहिष्कृत |
<DisplayName> एलिमेंट
इस कॉलम में नीति को लेबल करने के लिए, name
एट्रिब्यूट के साथ-साथ इस्तेमाल करें
मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर, जिसका नाम अलग और सामान्य भाषा में है.
<DisplayName>Policy Display Name</DisplayName>
डिफ़ॉल्ट |
लागू नहीं अगर आप इस एलिमेंट को छोड़ देते हैं, तो नीति की |
---|---|
मौजूदगी | वैकल्पिक |
टाइप | स्ट्रिंग |
<CacheKey> एलिमेंट
यह कैश मेमोरी में सेव किए गए डेटा के किसी हिस्से का यूनीक पॉइंटर कॉन्फ़िगर करता है.
कैश कुंजियों का साइज़ 2 केबी से ज़्यादा नहीं होना चाहिए.
<CacheKey> <Prefix>string</Prefix> <KeyFragment ref="variable_name" /> <KeyFragment>literal_string</KeyFragment> </CacheKey>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी है |
टाइप: |
लागू नहीं |
<CacheKey>
, कैश मेमोरी में सेव किए गए डेटा के हर हिस्से का नाम बनाता है.
कुंजी को अक्सर इकाई हेडर या क्वेरी पैरामीटर के मान का इस्तेमाल करके सेट किया जाता है. ऐसे मामलों में, आपको
रखें कि एलिमेंट का ref एट्रिब्यूट, की वैल्यू वाला वैरिएबल तय करे.
रनटाइम पर, <KeyFragment>
वैल्यू को, वैल्यू के पहले जोड़े गए
<Scope>
एलिमेंट वैल्यू या <Prefix>
वैल्यू. उदाहरण के लिए,
परिणामों की एक कैश कुंजी
UserToken__apiAccessToken__
<value_of_client_id>:
<CacheKey> <Prefix>UserToken</Prefix> <KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" /> </CacheKey>
<CacheKey>
एलिमेंट का इस्तेमाल इसके साथ किया जाता है
<Prefix>
और <Scope>
. ज़्यादा जानकारी के लिए, कैश मेमोरी में सेव की जाने वाली कुंजियों के साथ काम करना लेख पढ़ें.
<CacheLookupTimeoutInSeconds> एलिमेंट
सेकंड की संख्या तय करता है. इसके बाद, असफल कैश लुकअप को कैश मेमोरी में सेव नहीं किया गया. अगर ऐसा होता है, तो कैश मेमोरी में सेव न किए जाने वाले पाथ पर फ़्लो फिर से शुरू हो जाता है.
<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>
डिफ़ॉल्ट: |
30 |
मौजूदगी: |
वैकल्पिक |
टाइप: |
पूर्णांक |
<CacheResource> एलिमेंट
उस कैश मेमोरी के बारे में बताता है जहां मैसेज सेव करने हैं. शामिल किए गए एलिमेंट का इस्तेमाल करने के लिए, इस एलिमेंट को छोड़ दें शेयर की गई कैश मेमोरी. अगर आपको कुछ कैश मेमोरी में मौजूद एंट्री को एडमिन के तौर पर हटाएं. इसके बारे में ज़्यादा जानने के लिए, कैश मेमोरी देखें.
<CacheResource>cache_to_use</CacheResource>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
कैश मेमोरी को कॉन्फ़िगर करने के बारे में ज़्यादा जानने के लिए, एनवायरमेंट बनाना और उसमें बदलाव करना देखें कैश मेमोरी में सेव करें.
<CacheKey>/<KeyFragment> एलिमेंट
इस नीति से एक ऐसी वैल्यू के बारे में पता चलता है जिसे कैश मेमोरी में सेव करने की कुंजी में शामिल किया जाना चाहिए. ऐसा करके, मैच करने के लिए नेमस्पेस बनाया जा सकता है कैश मेमोरी में सेव किए गए जवाबों के लिए अनुरोध.
<KeyFragment ref="variable_name"/> <KeyFragment>literal_string</KeyFragment>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
लागू नहीं |
यह कोई कुंजी (आपकी ओर से उपलब्ध कराया जाने वाला स्टैटिक नाम) या कोई वैल्यू (डाइनैमिक एंट्री सेट वैरिएबल का रेफ़रंस देते हैं). सभी तय फ़्रैगमेंट (साथ ही प्रीफ़िक्स) जोड़े गए हैं कैश मेमोरी कुंजी बनाएं.
<KeyFragment>apiAccessToken</KeyFragment> <KeyFragment ref="request.queryparam.client_id" />
<KeyFragment>
एलिमेंट का इस्तेमाल इसके साथ किया जाता है
<Prefix>
और <Scope>
. ज़्यादा जानकारी के लिए, कैश मेमोरी में सेव की जाने वाली कुंजियों के साथ काम करना लेख पढ़ें.
विशेषताएं
एट्रिब्यूट | टाइप | डिफ़ॉल्ट | ज़रूरी है | ब्यौरा |
---|---|---|---|---|
संदर्भ | स्ट्रिंग | नहीं |
वह वैरिएबल जिससे वैल्यू पाना है. अगर इस एलिमेंट में ये चीज़ें शामिल हैं, तो इसका इस्तेमाल नहीं करना चाहिए लिटरल वैल्यू होती है. |
<CacheKey>/<Prefix> एलिमेंट
यह कैश मेमोरी की कुंजी के प्रीफ़िक्स के तौर पर इस्तेमाल की जाने वाली वैल्यू के बारे में बताता है.
<Prefix>prefix_string</Prefix>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
जब आपको अपना मान तय करना हो, तो <Scope>
के बजाय इस मान का इस्तेमाल करें
के बजाय <Scope>
-एन्युरेटेड वैल्यू डाली जा सकती है. अगर तय किया गया हो,
<Prefix>
, कैश मेमोरी में लिखी गई एंट्री के लिए, कैश मेमोरी की कुंजी की वैल्यू को जोड़ता है. ऐप्लिकेशन
<Prefix>
एलिमेंट की वैल्यू, <Scope>
एलिमेंट को बदल देती है
वैल्यू.
<Prefix>
एलिमेंट का इस्तेमाल इसके साथ किया जाता है
<CacheKey>
और <Scope>
. ज़्यादा जानकारी के लिए, कैश मेमोरी में सेव की जाने वाली कुंजियों के साथ काम करना लेख पढ़ें.
<ExcludeErrorResponse> एलिमेंट
फ़िलहाल, यह नीति डिफ़ॉल्ट रूप से किसी भी संभव एचटीटीपी रिस्पॉन्स को कैश मेमोरी में सेव करती है स्थिति कोड. इसका मतलब है कि सक्सेस (सफलता) और गड़बड़ी (गड़बड़ी) वाले रिस्पॉन्स, दोनों को कैश मेमोरी में सेव किया जाता है. उदाहरण के लिए, 2xx और 3xx दोनों स्टेटस कोड, डिफ़ॉल्ट रूप से कैश मेमोरी में सेव किए जाते हैं.
अगर आपको टारगेट कैश मेमोरी में सेव नहीं करना है, तो इस एलिमेंट को true
पर सेट करें
एचटीटीपी गड़बड़ी वाले स्टेटस कोड के साथ रिस्पॉन्स; सिर्फ़ 200 से 205 तक के स्टेटस कोड वाले रिस्पॉन्स मिलेंगे
कैश मेमोरी में सेव किया जाएगा, अगर यह एलिमेंट सही है. Edge को सिर्फ़ इन एचटीटीपी स्टेटस कोड के तौर पर गिना जाता है
"सफलता" कोड के साथ किया जा सकता है और इस असोसिएशन को नहीं बदला जा सकता.
रिस्पॉन्स कैश पैटर्न के बारे में चर्चा करने के लिए, जिसमें यह एलिमेंट काम का है, यह कम्यूनिटी पोस्ट देखें.
ध्यान दें: आने वाली रिलीज़ (तय की जाने वाली) में, इस सेटिंग की डिफ़ॉल्ट सेटिंग तत्व सही में बदल जाएगा. Apigee देखें प्रॉडक्ट की जानकारी देखें.
<ExcludeErrorResponse>true</ExcludeErrorResponse>
डिफ़ॉल्ट: |
गलत |
मौजूदगी: |
वैकल्पिक |
टाइप: |
बूलियन |
<ExpirySettings> एलिमेंट
इस नीति से पता चलता है कि कैश मेमोरी में सेव की गई एंट्री की समयसीमा कब खत्म होनी चाहिए. मौजूद होने पर, <TimeoutInSeconds>
<TimeOfDay>
और <ExpiryDate>
, दोनों को ओवरराइड करता है.
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> <ExpiryDate ref="date_variable">expiration_date</ExpiryDate> </ExpirySettings>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
ज़रूरी है |
टाइप: |
लागू नहीं |
<ExpirySettings>/<ExpiryDate> एलिमेंट
कैश मेमोरी में सेव की गई एंट्री की समयसीमा खत्म होने की तारीख के बारे में बताता है. mm-dd-yyyy
फ़ॉर्म का इस्तेमाल करें.
मौजूद होने पर, इस एलिमेंट का सिबलिंग, <TimeoutInSeconds>
बदल जाता है
<ExpiryDate>
.
<ExpirySettings> <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate> </ExpirySettings>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
विशेषताएं
<ExpiryDate ref="" />
एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी | टाइप |
---|---|---|---|---|
संदर्भ |
वह वैरिएबल जिससे वैल्यू पाना है. अगर इस एलिमेंट में ये चीज़ें शामिल हैं, तो इसका इस्तेमाल नहीं करना चाहिए लिटरल वैल्यू होती है. |
लागू नहीं | वैकल्पिक | स्ट्रिंग |
<ExpirySettings>/<TimeOfDay> एलिमेंट
दिन का वह समय जब कैश एंट्री की समयसीमा खत्म हो जानी चाहिए. hh:mm:ss
फ़ॉर्म का इस्तेमाल करें .
मौजूद होने पर, इस एलिमेंट का सिबलिंग, <TimeoutInSeconds>
बदल जाता है
<TimeOfDay>
.
HH:mm:ss फ़ॉर्मैट में दिन का समय डालें. यहां HH, 24 घंटे की घड़ी में घंटे को दिखाता है. इसके लिए उदाहरण के लिए, दोपहर 2:30 के लिए 14:30:00.
दिन के समय के लिए, डिफ़ॉल्ट स्थान और समय क्षेत्र इस आधार पर अलग-अलग होंगे कि कोड कहां है (जिसके बारे में नीति को कॉन्फ़िगर करते समय पता नहीं चलता). अपने कस्टम पैरामीटर को कॉन्फ़िगर करने के बारे में जानकारी पाने के लिए स्थान-भाषा के लिए, किसी एनवायरमेंट कैश मेमोरी.
<ExpirySettings> <TimeOfDay ref="time_variable">expiration_time</TimeOfDay> </ExpirySettings>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
विशेषताएं
एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी | टाइप |
---|---|---|---|---|
संदर्भ | खत्म होने की तारीख की वैल्यू वाला वैरिएबल. | लागू नहीं | वैकल्पिक | स्ट्रिंग |
<ExpirySettings>/<TimeoutInSec> एलिमेंट
कैश मेमोरी में सेव किया गया डेटा कितने सेकंड बाद खत्म हो जाएगा.
<ExpirySettings>/<TimeoutInSeconds> एलिमेंट
कैश मेमोरी में सेव किया गया डेटा कितने सेकंड बाद खत्म हो जाएगा. मौजूद होने पर, यह एलिमेंट
अपने सिबलिंग, <TimeOfDay>
और <ExpiryDate>
को ओवरराइड करता है.
<ExpirySettings> <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds> </ExpirySettings>
ध्यान दें: अगर रेफ़र को
duration_variable
.
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
विशेषताएं
एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी | टाइप |
---|---|---|---|---|
संदर्भ | टाइम आउट वैल्यू वाला वैरिएबल. |
लागू नहीं
|
वैकल्पिक | स्ट्रिंग |
<Scope> एलिमेंट
<Prefix>
के समय कैश मेमोरी में सेव की गई कुंजी के लिए प्रीफ़िक्स बनाने के लिए इस्तेमाल किया जाने वाला इन्यूमरेशन
<CacheKey>
एलिमेंट में एलिमेंट की वैल्यू नहीं दी गई है.
<Scope>scope_enumeration</Scope>
डिफ़ॉल्ट: |
"खास" |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
<Scope>
सेटिंग एक कैश कुंजी तय करती है, जिसे
<Scope>
वैल्यू. उदाहरण के लिए, कैश मेमोरी में सेव की गई कुंजी को ऐसा तब माना जाएगा, जब
दायरा Exclusive
पर सेट है :
orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [
serializedCacheKey ].
अगर <CacheKey>
में <Prefix>
एलिमेंट मौजूद है, तो इसका मतलब है कि
<Scope>
एलिमेंट की वैल्यू की जगह लागू होता है. मान्य वैल्यू में, गिनती शामिल हैं
देखें.
<Scope>
एलिमेंट का इस्तेमाल इसके साथ किया जाता है
<CacheKey>
और <Prefix>
. ज़्यादा जानकारी के लिए, कैश मेमोरी में सेव की जाने वाली कुंजियों के साथ काम करना लेख पढ़ें.
स्वीकार की जा सकने वाली वैल्यू
दायरे की वैल्यू | ब्यौरा |
---|---|
Global |
कैश मेमोरी की कुंजी, एनवायरमेंट में डिप्लॉय की गई सभी एपीआई प्रॉक्सी के साथ शेयर की जाती है. कैश कुंजी है orgName __ envName __ के फ़ॉर्म में पहले से जोड़ा जाता है. यदि आप कोई |
Application |
एपीआई प्रॉक्सी के नाम का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है. कैश कुंजी को orgName__envName__apiProxyName के फ़ॉर्म में पहले से जोड़ा जाता है. |
Proxy |
प्रॉक्सीएंडपॉइंट कॉन्फ़िगरेशन का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है. कैश कुंजी को फ़ॉर्म में पहले से जोड़ा गया है orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName |
Target |
TargetEndpoint कॉन्फ़िगरेशन का इस्तेमाल प्रीफ़िक्स के तौर पर किया जाता है. कैश कुंजी को फ़ॉर्म में पहले से जोड़ा गया है orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName . |
Exclusive |
डिफ़ॉल्ट. यह सबसे खास है और इसलिए, नेमस्पेस का जोखिम भी कम होता है किसी दिए गए कैश में टकराव. प्रीफ़िक्स दो तरह का है:
कैश कुंजी को फ़ॉर्म में पहले से जोड़ा गया है orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName उदाहरण के लिए, पूरी स्ट्रिंग कुछ ऐसी दिख सकती है: apifactory__test__weatherapi__16__default__apiAccessToken |
<SkipCacheLookup> एलिमेंट
इस नीति से एक एक्सप्रेशन तय होता है, जो रनटाइम के दौरान 'सही' के तौर पर मार्क होता है. साथ ही, उस कैश लुकअप के बारे में बताता है को छोड़ दिया जाना चाहिए और कैश मेमोरी को रीफ़्रेश किया जाना चाहिए. इसे भी देखें वीडियो के बारे में ज़्यादा जानें.
<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
यहां दिए गए उदाहरण से, अगर बायपास-कैश वैरिएबल को किसी आने वाले हेडर में 'सही' पर सेट किया गया है, कैश लुकअप को स्किप किया गया और कैश मेमोरी को रीफ़्रेश किया गया.
<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>
<SkipCachePopulation> एलिमेंट
इस एक्सप्रेशन से यह पता चलता है कि अगर रनटाइम के दौरान इसकी वैल्यू 'सही' के तौर पर दिखती है, तो कैश मेमोरी को छोड़ देना चाहिए. इसे भी देखें वीडियो के बारे में ज़्यादा जानें.
<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>
डिफ़ॉल्ट: |
लागू नहीं |
मौजूदगी: |
वैकल्पिक |
टाइप: |
स्ट्रिंग |
उदाहरण के लिए, अगर रिस्पॉन्स स्टेटस कोड 400 या ज़्यादा:
<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>
<UseAcceptHeader> एलिमेंट
रिस्पॉन्स कैश एंट्री की कैश कुंजी को इन वैल्यू से जोड़ने के लिए, true
पर सेट करें
जवाब, हेडर स्वीकार करें.
Edge, Accept
, Accept-Encoding
, और Accept-Language
का इस्तेमाल करता है
और Accept-Charset
कैश मेमोरी की कुंजी का हिसाब लगाते समय, हेडर का अनुरोध करता है. यह तरीका
क्लाइंट को वह मीडिया टाइप पाने से रोकता है जिसके लिए उसने अनुरोध नहीं किया था.
उदाहरण के लिए, अगर एक ही यूआरएल से दो अनुरोध आते हैं, जिनमें पहला अनुरोध gzip स्वीकार करता है और दूसरे में नहीं. पहले अनुरोध को कैश मेमोरी में सेव किया जाएगा और कैश मेमोरी में सेव की गई एंट्री को (शायद) एक gzip किया गया जवाब होगा. दूसरा अनुरोध कैश मेमोरी में सेव किए गए मान को पढ़ेगा और तब क्लाइंट को gzip की गई एंट्री मिलेगी, जो gzip पढ़ने में सक्षम नहीं है.
ज़्यादा जानकारी के लिए कैश कुंजी कॉन्फ़िगर करना देखें.
<UseAcceptHeader>false</UseAcceptHeader>
डिफ़ॉल्ट: |
गलत |
मौजूदगी: |
वैकल्पिक |
टाइप: |
बूलियन |
<UseResponseCacheHeaders> एलिमेंट
"time to सेट" करते समय एचटीटीपी रिस्पॉन्स हेडर को ध्यान में रखने के लिए true
पर सेट करें
लाइव" (TTL) कैश मेमोरी में सेव किए गए रिस्पॉन्स का. जब यह सही होता है, तो Edge
रिस्पॉन्स हेडर देखकर.
लाइव जाने का समय सेट करते समय <ExpirySettings>
:
Cache-Control s-maxage
Cache-Control max-age
Expires
ज़्यादा जानकारी के लिए, कैश मेमोरी में डेटा दिखने की समयसीमा सेट करना लेख पढ़ें विवरण.
<UseResponseCacheHeaders>false</UseResponseCacheHeaders>
डिफ़ॉल्ट: |
गलत |
मौजूदगी: |
वैकल्पिक |
टाइप: |
बूलियन |
इस्तेमाल की जानकारी
कैश मेमोरी में सेव किए गए हर ऑब्जेक्ट का ज़्यादा से ज़्यादा साइज़ 256 केबी हो सकता है. (Edge कैसे जनरेट किया जा रहा है कैशे को प्रोसेस करता है, कैशे देखें इंंटरनल.)
रिस्पॉन्स कैश नीति में कॉन्फ़िगरेशन के ज़रिए, आप Edge में एचटीटीपी रिस्पॉन्स शामिल कर सकते हैं हेडर का इस्तेमाल करें. इस सेक्शन में बताया गया है कि कैश मेमोरी की समयसीमा खत्म होने की तारीख और कैश कुंजियों को मैनेज करने के लिए, हेडर वाली नीति का इस्तेमाल करें.
Edge, Responseकैश नीति के साथ रिस्पॉन्स हेडर को कैसे मैनेज करता है, इसके बारे में ज़्यादा जानने के लिए एचटीटीपी रिस्पॉन्स हेडर के लिए सहायता लेख पढ़ें.
कैश एंट्री की समयसीमा सेट करना
पॉप्युलेट की तरह
कैश नीति है, तो आप
<ExpirySettings>
एलिमेंट. रिस्पॉन्स कैश की नीति में, आपके पास Edge भी इस्तेमाल करने का विकल्प होता है
रिस्पॉन्स हेडर के मौजूद होने पर उन पर विचार करें.
रिस्पॉन्स हेडर का इस्तेमाल करने के लिए, <UseResponseCacheHeaders>
एलिमेंट की वैल्यू को इस पर सेट करें:
सही है. इस सेटिंग की वजह से Edge रिस्पॉन्स हेडर का इस्तेमाल करता है और वैल्यू सेट से उनकी तुलना करता है
<ExpirySettings>
से, फिर दोनों के बीच सबसे कम मान का उपयोग करें. टास्क कब शुरू होगा
रिस्पॉन्स हेडर को ध्यान में रखते हुए, Edge
फ़ॉलो किया जा रहा है:
उदाहरण के लिए, मान लें कि नीचे दी गई वैल्यू की मदद से, रिस्पॉन्स को कैश मेमोरी में सेव किया जाता है:
- कोई
Cache-Control s-maxage
मान नहीं - 300 की
Cache-Control max-age
वैल्यू - तीन दिनों में
Expires
की तारीख <ExpirySettings>
TimeoutInSeconds
की वैल्यू 600.
इस मामले में, Cache-Control
max-age
वैल्यू का इस्तेमाल
TTL (टीटीएल) क्योंकि यह <ExpirySettings>
मान से कम है और
कोई Cache-Control s-maxage
मान नहीं (जिसकी अहमियत
max-age
).
कैश कुंजी को कॉन्फ़िगर करना
सामान्य मकसद वाली कैश मेमोरी की नीतियों, जैसे कि कैश मेमोरी में जानकारी अपने-आप भरने की नीति की तरह ही,
जवाब कैश मेमोरी में सेव करने के लिए, आप <CacheKey>
और <Scope>
एलिमेंट का इस्तेमाल करते हैं
कैश एंट्री के लिए, कैश मेमोरी में सेव की जाने वाली कुंजी बनाने की सुविधा को कॉन्फ़िगर करें. जवाब कैश मेमोरी में सेव करने के लिए कैश मेमोरी का इस्तेमाल भी किया जा सकता है
मुख्य वैल्यू में रिस्पॉन्स स्वीकार हेडर जोड़कर ज़्यादा बेहतर नतीजे पाएं.
कैश कुंजियों को कॉन्फ़िगर करने के बारे में सामान्य जानकारी के लिए, कैश कुंजियों के साथ काम करना देखें. इसके लिए
स्वीकार करें हेडर इस्तेमाल करने के बारे में ज़्यादा जानकारी के लिए, <UseAcceptHeader>
देखें.
कैश मेमोरी में सेव डेटा को एन्क्रिप्ट (सुरक्षित) करने के बारे में जानकारी
Edge for Public Cloud: कैश मेमोरी को सिर्फ़ एन्क्रिप्ट (सुरक्षित) किया जाता है PCI- और HIPAA की सुविधा चालू हो संगठनों ने. उन संगठनों के लिए एन्क्रिप्ट (सुरक्षित) करने का तरीका, संगठन के दौरान कॉन्फ़िगर किया गया है प्रॉविज़निंग.
फ़्लो वैरिएबल
रिस्पॉन्स कैश नीति के लागू होने पर, पहले से तय फ़्लो वैरिएबल में जानकारी अपने-आप भर जाती है. फ़्लो वैरिएबल के बारे में ज़्यादा जानकारी के लिए, वैरिएबल रेफ़रंस देखें.
वैरिएबल | टाइप | अनुमति | ब्यौरा |
---|---|---|---|
responsecache.{policy_name}.cachename |
स्ट्रिंग | रीड-ओनली | नीति में इस्तेमाल की गई कैश मेमोरी दिखाता है |
responsecache.{policy_name}.cachekey |
स्ट्रिंग | रीड-ओनली | इस्तेमाल की गई कुंजी वापस भेजता है |
responsecache.{policy_name}.cachehit |
बूलियन | रीड-ओनली | अगर नीति लागू हो जाती है, तो वैल्यू 'सही' होगी |
responsecache.{policy_name}.invalidentry |
बूलियन | रीड-ओनली | अगर कैश मेमोरी की एंट्री मान्य नहीं है, तो वैल्यू 'सही' होगी |
गड़बड़ी कोड
This section describes the error messages and flow variables that are set when this policy triggers an error. This information is important to know if you are developing fault rules for a proxy. To learn more, see What you need to know about policy errors and Handling faults.
Error code prefix
N/A
Runtime errors
This policy does not throw any runtime errors.
Deployment errors
These errors can occur when you deploy a proxy containing this policy.
Error name | Cause | Fix |
---|---|---|
InvalidTimeout |
If the
<CacheLookupTimeoutInSeconds> element of the ResponseCache policy is set to a negative number,
then the deployment of the API proxy fails. |
build |
InvalidCacheResourceReference |
This error occurs if the <CacheResource> element in a ResponseCache policy is set to a
name that does not exist in the environment where the API proxy is being deployed. |
build |
ResponseCacheStepAttachmentNotAllowedReq |
This error occurs if the same ResponseCache policy is attached to multiple request paths within any flows of an API proxy. | build |
ResponseCacheStepAttachmentNotAllowedResp |
This error occurs if the same ResponseCache policy is attached to multiple response paths within any flows of an API proxy. | build |
InvalidMessagePatternForErrorCode |
This error occurs if either the <SkipCacheLookup> or the <SkipCachePopulation>
element in a ResponseCache policy contains an invalid condition. |
build |
CacheNotFound |
This error occurs if the specific cache mentioned in the error message has not been created on a specific Message Processor component. | build |
Fault variables
N/A
Example error response
N/A
स्कीमा
हर तरह की नीति को एक्सएमएल स्कीमा (.xsd
) से तय किया जाता है. रेफ़रंस के लिए, नीति के स्कीमा
GitHub पर उपलब्ध हैं.