ResponseCache-Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Speichert Daten aus einer Backend-Ressource im Cache, wodurch die Anzahl der Anfragen an die Ressource reduziert wird. Wenn Anwendungen Anfragen an denselben URI senden, können Sie mit dieser Richtlinie im Cache gespeicherte Antworten zurückgeben, anstatt diese Anfragen an den Back-End-Server weiterzuleiten. Die ResponseCache-Richtlinie kann die Leistung Ihrer API durch reduzierte Latenz und reduzierten Netzwerktraffic verbessern.

Diese Richtlinie ist eine erweiterbare Richtlinie, deren Verwendung je nach Apigee-Lizenz Auswirkungen auf die Kosten oder die Nutzung haben kann. Informationen zu Richtlinientypen und Auswirkungen auf die Nutzung finden Sie unter Richtlinientypen.

Wahrscheinlich finden Sie ResponseCache am nützlichsten, wenn die von Ihrer API verwendeten Backend-Daten nur in bestimmten Abständen aktualisiert werden. Angenommen, Sie haben eine API, die Wetterberichtsdaten nur alle 10 Minuten aktualisiert. Wenn Sie ResponseCache verwenden, um im Cache gespeicherte Antworten zwischen Aktualisierungen zurückzugeben, können Sie die Anzahl der Anfragen verringern, die das Back-End erreichen. Hierdurch wird auch die Anzahl der Netzwerk-Hops reduziert.

Für kurzfristiges Speichern im Cache für allgemeine Zwecke kann es sinnvoll sein, die PopulateCache-Richtlinie zu verwenden. Diese Richtlinie wird in Verbindung mit der LookupCache-Richtlinie (zum Lesen von Cache-Einträgen) und der InvalidateCache-Richtlinie (zum Entwerten von Einträgen) verwendet.

Im folgenden Video erhalten Sie eine Einführung in die ResponseCache-Richtlinie.

Tipp: Eine Erläuterung von Antimustern der ResponseCache-Richtlinie finden Sie unter Einführung in Antimuster.

Hinweis: Sie können diese Richtlinie nur einmal im Proxy-Anfrageablauf und einmal im Antwortablauf anhängen. Eine Videoanleitung finden Sie unter Anleitung: Response-Caching in Edge implementieren. Weitere Informationen finden Sie unter Fehlercodes.

Beispiele

10-Minuten-Cache

In diesem Beispiel wird gezeigt, wie Antworten im Cache für zehn Minuten gespeichert werden.

Angenommen, Sie haben eine API unter der folgenden URL:

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

Sie verwenden den Abfrageparameter w als Cache-Schlüssel. Apigee prüft den Wert für den Abfrageparameter w, wenn eine Anfrage empfangen wird. Wenn der Cache eine gültige Antwort (also nicht abgelaufen) enthält, wird die im Cache gespeicherte Antwortnachricht an den anfordernden Client zurückgegeben.

Angenommen, Sie haben eine ResponseCache-Richtlinie mit folgender Konfiguration:

<ResponseCache name="ResponseCache">
    <CacheKey>
        <KeyFragment ref="request.queryparam.w" />
    </CacheKey>
    <ExpirySettings>
        <TimeoutInSeconds>600</TimeoutInSeconds>
    </ExpirySettings>
</ResponseCache>

Wenn der API-Proxy zum ersten Mal eine Anfragenachricht für die folgende URL empfängt, wird die Antwort im Cache gespeichert. Bei der zweiten Anfrage erfolgt innerhalb von zehn Minuten eine Cache-Suche. Die im Cache gespeicherte Antwort wird ohne Anforderung an den Back-End-Dienst an die Anwendung zurückgegeben.

http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778

Tipp: HTTP-Header und Abfrageparameter werden automatisch als Variablen erfasst, wenn eine Anfrage empfangen wird. Jeder HTTP-Header ist als request.header.{header_name} verfügbar, z. B. request.header.user-agent. Jeder Abfrageparameter ist als request.queryparam.{queryparam_name} verfügbar, z. B. request.queryparam.action.

Cache-Suche überspringen

Das folgende Beispiel zeigt, wie Sie die Cache-Suche überspringen und den Cache aktualisieren. Weitere Informationen zur Verwendung von SkipCacheLookup finden Sie in diesem Video.

Die optionale Bedingung „SkipCacheLookup“ (falls konfiguriert) wird im Anfragepfad ausgewertet. Wenn die Bedingung als „true“ ausgewertet wird, wird der Cache-Suchvorgang übersprungen und der Cache wird aktualisiert.

Eine häufige Verwendung der bedingten Cache-Aktualisierung ist eine Bedingung, die einen bestimmten HTTP-Header definiert, der bewirkt, dass die Bedingung als „true“ ausgewertet wird. Eine skriptbasierte Clientanwendung kann so konfiguriert werden, dass sie regelmäßig eine Anfrage mit dem entsprechenden HTTP-Header sendet, was explizit zu einer Aktualisierung des Antwortcache führt.

Stellen Sie sich beispielsweise den Aufruf einer API unter der folgenden URL vor:

'http://{org_name}-test.apigee.net/weather/forecastrss?w=23424778' -H "bypass-cache:true"

Betrachten Sie nun die folgende ResponseCache-Richtlinie, die für diesen Proxy konfiguriert ist. Beachten Sie, dass die Bypass-Cache-Bedingung auf „true” gesetzt ist.

<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>

Weitere Informationen zu Bedingungen finden Sie unter Ablaufvariablen und -bedingungen.

Elementverweis

Die Elementreferenz beschreibt die Elemente und Attribute der Richtlinie:

<?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>-Attribute

<ResponseCache async="false" continueOnError="false" enabled="true" name="Response-Cache-1">

The following table describes attributes that are common to all policy parent elements:

Attribute	Description	Default	Presence
name	The internal name of the policy. The value of the name attribute can contain letters, numbers, spaces, hyphens, underscores, and periods. This value cannot exceed 255 characters. Optionally, use the <DisplayName> element to label the policy in the management UI proxy editor with a different, natural-language name.	N/A	Required
continueOnError	Set to false to return an error when a policy fails. This is expected behavior for most policies. Set to true to have flow execution continue even after a policy fails. See also: Fault rules are triggered ONLY in an error state (about continueOnError) Handling faults within the current flow	false	Optional
enabled	Set to true to enforce the policy. Set to false to turn off the policy. The policy will not be enforced even if it remains attached to a flow.	true	Optional
async	This attribute is deprecated.	false	Deprecated

<DisplayName> element

Use in addition to the name attribute to label the policy in the management UI proxy editor with a different, natural-language name.

<DisplayName>Policy Display Name</DisplayName>

Default	N/A If you omit this element, the value of the policy's name attribute is used.
Presence	Optional
Type	String

<CacheKey>-Element

Konfiguriert einen eindeutigen Zeiger auf ein im Cache gespeichertes Datenelement.

Cache-Schlüssel sind auf eine Größe von 2 KB begrenzt.

Hinweis: Sie können den hier konfigurierten Cache-Schlüssel auch mit Werten aus Antwortheadern erweitern. Weitere Informationen finden Sie unter Cache-Schlüssel konfigurieren.

<CacheKey>
    <Prefix>string</Prefix>
    <KeyFragment ref="variable_name" />
    <KeyFragment>literal_string</KeyFragment>
</CacheKey>

Standard:	–
Präsenz:	Erforderlich
Typ:	–

<CacheKey> erstellt den Namen jedes Datenelements, das im Cache gespeichert ist. Der Schlüssel wird häufig mithilfe eines Werts aus Entitäts-Headern oder Abfrageparametern festgelegt. In diesen Fällen hätte das Attribut „ref” des Elements eine Variable enthalten, die den Schlüsselwert enthält.

Zur Laufzeit werden <KeyFragment>-Werte entweder dem <Scope>-Elementwert oder dem <Prefix>-Wert vorangestellt. Das folgende Beispiel führt zu einem Cacheschlüssel von UserToken__apiAccessToken__<value_of_client_id>:

<CacheKey>
    <Prefix>UserToken</Prefix>
    <KeyFragment>apiAccessToken</KeyFragment>
    <KeyFragment ref="request.queryparam.client_id" />
</CacheKey>

Sie verwenden das <CacheKey>-Element zusammen mit <Prefix> und <Scope>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

<CacheLookupTimeoutInSeconds>-Element

Gibt die Anzahl der Sekunden an, nach denen eine fehlgeschlagene Cache-Suche als Cache-Fehler betrachtet wird. In diesem Fall wird der Ablauf entlang des Cache-Fehler-Pfads fortgesetzt.

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

Standard:	30
Präsenz:	Optional
Typ:	Ganzzahl

<CacheResource>-Element

Gibt den Cache an, in dem Nachrichten gespeichert werden sollen. Lassen Sie dieses Element aus, um den enthaltenen freigegebenen Cache zu verwenden. Geben Sie einen CacheResource-Namen an, wenn Sie Einträge im Cache administrativ löschen möchten. Weitere Informationen dazu finden Sie unter Caches API.

<CacheResource>cache_to_use</CacheResource>

Standard:	–
Präsenz:	Optional
Typ:	String

<CacheKey>/<KeyFragment>-Element

Gibt einen Wert an, der im Cache-Schlüssel enthalten sein muss, um einen Namespace für den Abgleich von Anfragen mit im Cache gespeicherten Antworten zu erstellen.

<KeyFragment ref="variable_name"/>
<KeyFragment>literal_string</KeyFragment>

Standard:	–
Präsenz:	Optional
Typ:	–

Dabei kann es sich um einen Schlüssel (einen von Ihnen angegebenen statischen Namen) oder um einen Wert (einen dynamischen Eintrag, der durch den Verweis auf eine Variable bestimmt wird) handeln. Alle angegebenen Fragmente werden (plus Präfix) verkettet, um den Cache-Schlüssel zu erstellen.

<KeyFragment>apiAccessToken</KeyFragment>
<KeyFragment ref="request.queryparam.client_id" />

Sie verwenden das <KeyFragment>-Element zusammen mit <Prefix> und <Scope>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

Attribute

Attribut	Typ	Standard	Erforderlich	Beschreibung
Ref	String		Nein	Die Variable, aus der der Wert abgerufen wird. Sollte nicht verwendet werden, wenn dieses Element einen Literalwert enthält.

<CacheKey>/<Prefix>-Element

Gibt den Wert an, der als Cache-Schlüsselpräfix verwendet werden soll.

<Prefix>prefix_string</Prefix>

Standard:	–
Präsenz:	Optional
Typ:	String

Verwenden Sie diesen Wert anstelle von <Scope>, wenn Sie einen eigenen Wert anstelle eines <Scope>-Aufzählungswerts angeben möchten. Wenn definiert, definiert <Prefix> den Cache-Schlüsselwert für Einträge, die in den Cache geschrieben werden. <Prefix>-Elementwerte überschreiben <Scope>-Elementwerte.

Sie verwenden das <Prefix>-Element zusammen mit <CacheKey> und <Scope>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

<ExcludeErrorResponse>-Element

Derzeit speichert diese Richtlinie HTTP-Antworten mit einem beliebigen möglichen Statuscode im Cache. Das heißt, sowohl die Erfolgs- als auch die Fehlerantworten werden im Cache gespeichert. Beispielsweise werden Antworten mit den Statuscodes 2xx und 3xx standardmäßig im Cache gespeichert.

Setzen Sie dieses Element auf true, wenn Sie Zielantworten mit HTTP-Fehlerstatuscodes nicht im Cache speichern möchten. Nur Antworten mit Statuscodes von 200 bis 205 werden im Cache gespeichert, wenn dieses Element „true“ ist. Dies sind die einzigen HTTP-Statuscodes, die von Apigee als „Erfolgscodes“ betrachtet werden. Diese Verknüpfung kann nicht geändert werden.

Eine Erläuterung der Antwortcachemuster, in denen dieses Element hilfreich ist, finden Sie unter Einführung in Antimuster.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

Standard:	false
Präsenz:	Optional
Typ:	Boolesch

<ExpirySettings>-Element

Gibt an, wann ein Cache-Eintrag ablaufen soll. Wenn vorhanden, überschreibt <TimeoutInSeconds> sowohl <TimeOfDay> als auch <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>

Standard:	–
Präsenz:	Erforderlich
Typ:	–

<ExpirySettings>/<ExpiryDate>-Element

Gibt das Datum an, an dem ein Cache-Eintrag ablaufen soll. Verwenden Sie das Format mm-dd-yyyy. Wenn dieses Element vorhanden ist, wird <ExpiryDate> vom gleichgeordneten Element <TimeoutInSeconds> überschrieben.

<ExpirySettings>
    <ExpiryDate ref="{date_variable}">expiration_date</ExpiryDate>
</ExpirySettings>

Standard:	–
Präsenz:	Optional
Typ:	String

Attribute

<ExpiryDate ref="" />

Attribut	Beschreibung	Standard	Präsenz	Typ
Ref	Die Variable, aus der der Wert abgerufen wird. Sollte nicht verwendet werden, wenn dieses Element einen Literalwert enthält.	–	Optional	String

<ExpirySettings>/<TimeOfDay>-Element

Die Tageszeit, zu der ein Cache-Eintrag ablaufen soll. Verwenden Sie das Format hh:mm:ss. Wenn dieses Element vorhanden ist, wird <TimeOfDay> vom gleichgeordneten Element <TimeoutInSeconds> überschrieben.

Geben Sie die Tageszeit im Format HH:mm:ss ein. Dabei steht HH für die Stunde im 24-Stunden-Format. Beispiel: 14:30:00 für 14:30 Uhr am Nachmittag.

In Bezug auf die Tageszeit variieren die Standardsprache und -zeitzone je nachdem, wo der Code ausgeführt wird. Das ist bei der Konfiguration der Richtlinie nicht bekannt.

<ExpirySettings>
    <TimeOfDay ref="time_variable">expiration_time</TimeOfDay>
</ExpirySettings>

Standard:	–
Präsenz:	Optional
Typ:	String

Attribute

Attribut	Beschreibung	Standard	Präsenz	Typ
Ref	Variable mit Ablaufzeitwert.	–	Optional	String

<ExpirySettings>/<TimeoutInSec>-Element

Hinweis: Wurde verworfen. Verwenden Sie TimeoutInSeconds. Wenn Elemente TimeoutInSec und TimeoutInSeconds beide vorhanden sind, verwendet Apigee TimeoutInSeconds.

Die Anzahl der Sekunden, nach denen ein Cache-Eintrag abläuft.

<ExpirySettings>/<TimeoutInSeconds>-Element

Die Anzahl der Sekunden, nach denen ein Cache-Eintrag abläuft. Wenn dieses Element vorhanden ist, überschreibt dieses Element seine gleichgeordneten Elemente <TimeOfDay> und <ExpiryDate>.

<ExpirySettings>
    <TimeoutInSeconds ref="duration_variable">seconds_until_expiration</TimeoutInSeconds>
</ExpirySettings>

Hinweis: Geben Sie einen Standardwert für die Zeitüberschreitung an, der verwendet werden soll, wenn "ref" keinen Wert aus der duration_variable empfängt.

Standard:	–
Präsenz:	Optional
Typ:	String

Attribute

Attribut	Beschreibung	Standard	Präsenz	Typ
Ref	Variable mit Zeitüberschreitungswert.	–	Optional	String

<Scope>-Element

Aufzählung, die zum Erstellen eines Präfixes für einen Cache-Schlüssel verwendet wird, wenn das Element <Prefix> nicht im Element <CacheKey> angegeben ist.

<Scope>scope_enumeration</Scope>

Standard:	"Exklusiv"
Präsenz:	Optional
Typ:	String

Mit der Einstellung <Scope> wird ein Cache-Schlüssel festgelegt, dem gemäß des Werts <Scope> etwas vorangestellt wird. Ein Cache-Schlüssel hat beispielsweise das folgende Format, wenn der Bereich auf Exclusive : orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [ serializedCacheKey ] festgelegt ist.

Ist in <CacheKey> ein <Prefix>-Element vorhanden, hat dies vor einem <Scope>-Elementwert Vorrang. Gültige Werte sind folgende Aufzählungen.

Sie verwenden das <Scope>-Element zusammen mit <CacheKey> und <Prefix>. Weitere Informationen finden Sie unter Mit Cache-Schlüsseln arbeiten.

Zulässige Werte

Bereichswert	Beschreibung
Global	Der Cache-Schlüssel wird für alle API-Proxys freigegeben, die in der Umgebung bereitgestellt werden. Der Cache-Schlüssel wird im Format orgName __ envName vorangestellt. Wenn Sie einen <CacheKey>-Eintrag mit dem <KeyFragment>-apiAccessToken und dem Bereich <Global> definieren, wird jeder Eintrag als orgName__envName__apiAccessToken gespeichert, gefolgt vom serialisierten Wert des Zugriffstokens. Für einen API-Proxy, der in einer Umgebung mit dem Namen "Test" in einer Organisation namens "apifactory" bereitgestellt wird, werden Zugriffstoken unter folgendem Cache-Schlüssel gespeichert: apifactory__test__apiAccessToken.
Application	Der API-Proxyname wird als Präfix verwendet. Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName vorangestellt.
Proxy	Die ProxyEndpoint-Konfiguration wird als Präfix verwendet. Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName vorangestellt.
Target	Die TargetEndpoint-Konfiguration wird als Präfix verwendet. Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName vorangestellt.
Exclusive	Standard. Dies ist die spezifischste Zuordnung und bedingt daher ein minimales Risiko in Sachen Namespace-Konflikten in einem bestimmten Cache. Das Präfix gibt es in zwei Formen: Wenn die Richtlinie an den Ablauf ProxyEndpoint angehängt wird, hat das Präfix das Format ApiProxyName_ProxyEndpointName. Wenn die Richtlinie unter TargetEndpoint angehängt wird, hat das Präfix das Format ApiProxyName_TargetName. Der Cache-Schlüssel wird im Format orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName angehängt. Der vollständige String kann so aussehen: apifactory__test__weatherapi__16__default__apiAccessToken .

<SkipCacheLookup>-Element

Definiert einen Ausdruck, der angibt, dass die Cache-Suche übersprungen und der Cache aktualisiert werden soll. Voraussetzung ist, dass der Ausdruck zur Laufzeit "true" ergibt. Siehe auch das Video zu ResponseCache-Richtlinien verwenden zur Verwendung von SkipCacheLookup.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

Standard:	–
Präsenz:	Optional
Typ:	String

Wenn im folgenden Beispiel die bypass-cache-Variable in einem eingehenden Header auf "true" gesetzt ist, wird die Cache-Suche übersprungen und der Cache wird aktualisiert.

<SkipCacheLookup>request.header.bypass-cache = "true"</SkipCacheLookup>

<SkipCachePopulation>-Element

Definiert einen Ausdruck, der bei Auswertung zur Laufzeit als „true“ angibt, dass ein Schreibvorgang in den Cache übersprungen werden soll. Weitere Informationen zur Verwendung von SkipCachePopulation finden Sie in diesem Video.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

Standard:	–
Präsenz:	Optional
Typ:	String

Im Folgenden wird beispielsweise der Cache-Schreibvorgang übersprungen, wenn der Statuscode der Antwort 400 oder höher war:

<SkipCachePopulation>response.status.code >= 400</SkipCachePopulation>

<UseAcceptHeader>-Element

Geben Sie true an, damit der Cache-Schlüssel eines Repository-Cache-Eintrags mit Werten aus Antwort-Accept-Headern angehängt wird.

Apigee verwendet für die Berechnung des Cache-Schlüssels die Anfrage-Header Accept, Accept-Encoding, Accept-Language und Accept-Charset. Dieser Ansatz verhindert, dass ein Client einen Medientyp erhält, nach dem er nicht gefragt hat.

Angenommen, zwei Anfragen stammen von derselben URL, wobei die erste Anfrage gzip akzeptiert und die zweite nicht. Die erste Anfrage wird im Cache gespeichert und der im Cache gespeicherte Eintrag ist (wahrscheinlich) eine mit gzip komprimierte Antwort. Die zweite Anfrage liest den im Cache gespeicherten Wert und kann dann einen gzip-Eintrag an einen Client zurückgeben, der gzip nicht lesen kann.

Weitere Informationen finden Sie unter Cache-Schlüssel konfigurieren.

<UseAcceptHeader>false</UseAcceptHeader>

Standard:	false
Präsenz:	Optional
Typ:	Boolesch

<UseResponseCacheHeaders>-Element

Legen Sie true fest, damit HTTP-Antwortheader beim Festlegen der Gültigkeitsdauer (TTL) der Antwort im Cache berücksichtigt werden. Wenn "true", berücksichtigt Apigee die Werte der folgenden Antwortheader und vergleicht die Werte mit den Werten, die durch <ExpirySettings> festgelegt wurden, als die Gültigkeitsdauer festgelegt wurde.

• Cache-Control s-maxage
• Cache-Control max-age
• Expires

Weitere Informationen finden Sie unter Ablauf von Cache-Eintrag festlegen.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

Standard:	false
Präsenz:	Optional
Typ:	Boolesch

Verwendungshinweise

Die maximale Größe für jedes im Cache gespeicherte Objekt beträgt 256 KB. Ausführliche Informationen zur Verarbeitung des Cache durch Apigee finden Sie unter Interne Strukturen des Cache.

Über die Konfiguration in der ResponseCache-Richtlinie können Sie festlegen, dass Apigee HTTP-Antwortheader für das Festlegen von Ablaufzeiten und Cache-Schlüsseln für Cache-Einträge enthält. In diesem Abschnitt wird beschrieben, wie Sie die Richtlinie mit Headern zur Verwaltung des Cache-Ablaufs und der Cache-Schlüssel verwenden können.

Weitere Informationen dazu, wie Apigee Antwortheader mit der ResponseCache-Richtlinie verarbeitet, finden Sie unter Unterstützung von HTTP-Antwortheadern.

Hinweis: Weitere Best Practices für die ResponseCache-Richtlinie finden Sie unter Best Practices für das Design und die Entwicklung von API-Proxys.

Ablauf von Cache-Eintrag festlegen

Wie auch bei der PopulateCache-Richtlinie können Sie mit dem Element <ExpirySettings> die Gültigkeitsdauer (TTL) eines Antwortcache festlegen. In der ResponseCache-Richtlinie können Sie auch festlegen, dass Apigee Antwortheader berücksichtigt, wenn sie vorhanden sind.

Wenn Sie Antwortheader verwenden möchten, setzen Sie den Elementwert <UseResponseCacheHeaders> auf „true“. Diese Einstellung bewirkt, dass Apigee die Antwortheader berücksichtigt, diese mit dem von <ExpirySettings> festgelegten Wert vergleicht und dann den niedrigsten Wert zwischen den beiden verwendet. Bei der Berücksichtigung von Antwortheadern wählt Apigee den verfügbaren Wert wie nachfolgend beschrieben aus:

Angenommen, eine Antwort wird mit den folgenden Werten im Cache gespeichert:

• Kein Cache-Control s-maxage-Wert
• Ein Cache-Control max-age-Wert von 300
• Ein Expires-Datum in drei Tagen
• Ein <ExpirySettings> TimeoutInSeconds-Wert von 600.

In diesem Fall wird der Wert Cache-Control max-age für die TTL verwendet, da diese unter dem Wert <ExpirySettings> liegt und kein Cache-Control s-maxage-Wert vorhanden ist, der Vorrang vor max-age hat.

Cache-Schlüssel konfigurieren

Wie auch bei Cache-Richtlinien mit allgemeinem Zweck wie der PopulateCache-Richtlinie verwenden Sie ResponseCache mit den Elementen <CacheKey> und <Scope>, um das Erstellen von Cache-Schlüsseln für Cache-Einträge zu konfigurieren. Mit ResponseCache können Sie Cache-Schlüssel auch aussagekräftiger gestalten, indem Sie festlegen, dass Antwort-Accept-Header an Schlüsselwerte angehängt werden.

Allgemeine Informationen zum Konfigurieren von Cache-Schlüsseln finden Sie unter Mit Cache-Schlüsseln arbeiten. Weitere Informationen zur Verwendung von Accept-Headern finden Sie unter <UseAcceptHeader>.

Informationen zur Cache-Verschlüsselung

Apigee und Apigee Hybrid (Version 1.4 und höher): Cache- und KVM-Daten werden immer verschlüsselt.

Ablaufvariablen

Die folgenden vordefinierten Ablaufvariablen werden erfasst, wenn eine ResponseCache-Richtlinie ausgeführt wird. Weitere Informationen zu Ablaufvariablen finden Sie in der Referenz zu Ablaufvariablen.

Variablen	Typ	Berechtigung	Beschreibung
responsecache.{policy_name}.cachename	String	Schreibgeschützt:	Gibt den in der Richtlinie verwendeten Cache zurück
responsecache.{policy_name}.cachekey	String	Schreibgeschützt:	Gibt den verwendeten Schlüssel zurück
responsecache.{policy_name}.cachehit	Boolesch	Schreibgeschützt:	TRUE, wenn die Ausführung der Richtlinie erfolgreich ist
responsecache.{policy_name}.invalidentry	Boolesch	Schreibgeschützt:	TRUE, wenn der Cache-Eintrag ungültig ist

Fehlercodes

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.

Tip: Need help resolving an error? Click in the Fix column for detailed troubleshooting information.

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.
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.
ResponseCacheStepAttachmentNotAllowedReq	This error occurs if the same ResponseCache policy is attached to multiple request paths within any flows of an API proxy.
ResponseCacheStepAttachmentNotAllowedResp	This error occurs if the same ResponseCache policy is attached to multiple response paths within any flows of an API proxy.
InvalidMessagePatternForErrorCode	This error occurs if either the <SkipCacheLookup> or the <SkipCachePopulation> element in a ResponseCache policy contains an invalid condition.
CacheNotFound	This error occurs if the specific cache mentioned in the error message has not been created on a specific Message Processor component.

Fault variables

N/A

Example error response

N/A

Schema

Jeder Richtlinientyp wird durch ein XML-Schema (.xsd) definiert. Zu Referenzzwecken sind Richtlinienschemas auf GitHub verfügbar.