Règle ResponseCache

Cette page s'applique à Apigee et à Apigee hybrid.

Consultez la documentation d'Apigee Edge.

La règle ResponseCache met en cache les données d'une ressource backend, ce qui réduit le nombre de requêtes adressées à la ressource. Lorsque des applications envoient des requêtes au même URI, vous pouvez utiliser cette règle pour renvoyer des réponses mises en cache au lieu de transférer ces requêtes au serveur backend. La règle ResponseCache peut améliorer les performances de votre API en réduisant la latence et le trafic réseau.

Cette règle est une règle extensible et son utilisation peut avoir des conséquences sur le coût ou l'utilisation, en fonction de votre licence Apigee. Pour en savoir plus sur les types de règles et les implications en termes d'utilisation, consultez la section Types de règles.

Vous trouverez probablement la règle ResponseCache très utile lorsque les données backend utilisées par votre API ne sont mises à jour que périodiquement. Imaginons, par exemple, que vous disposiez d'une API qui expose les données du rapport météorologique actualisées toutes les 10 minutes. En utilisant la règle ResponseCache pour renvoyer des réponses mises en cache entre les actualisations, vous pouvez réduire le nombre de requêtes atteignant le backend. Cela réduit également le nombre de sauts de réseau.

Pour une mise en cache générale à court terme, pensez à utiliser la règle PopulateCache. Cette règle est utilisée avec la règle LookupCache (pour la lecture des entrées de cache) et la règle InvalidateCache (pour l'invalidation des entrées).

Regardez la vidéo ci-dessous pour découvrir la règle de mise en cache de réponse.

Conseil : Pour en savoir plus sur les antimodèles pour la règle ResponseCache, consultez la section Introduction aux antimodèles.

Remarque : Vous ne pouvez associer cette règle qu'une seule fois dans le flux de requête proxy et dans le flux de réponse. Pour consulter un tutoriel vidéo, consultez la page Tutoriel : Implémentation de la mise en cache des réponses dans Edge. Consultez également la section Codes d'erreur ci-dessous.

Exemples

Cache de 10 minutes

Cet exemple montre comment conserver des réponses mises en cache pendant 10 minutes.

Imaginons que vous disposiez d'une API à l'URL suivante :

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

Vous utilisez le paramètre de requête w en tant que clé de cache. Apigee vérifie la valeur du paramètre de requête w chaque fois qu'une requête est reçue. Si une réponse valide (non expirée) est présente dans le cache, le message de réponse mis en cache est renvoyé au client demandeur.

Imaginons maintenant que vous disposiez d'une stratégie ResponseCache configurée comme suit :

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

La première fois que le proxy d'API reçoit un message de requête pour l'URL suivante, la réponse est mise en cache. À la deuxième requête dans les 10 minutes, une recherche est effectuée dans le cache : la réponse mise en cache est renvoyée à l'application sans requête transférée vers le service de backend.

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

Conseil : Les en-têtes HTTP et les paramètres de requête sont automatiquement définis en tant que variables lorsqu'une requête est reçue. Un en-tête HTTP est disponible en tant que request.header.{header_name} (par exemple, request.header.user-agent). Un paramètre de requête est disponible en tant que request.queryparam.{queryparam_name}, par exemple request.queryparam.action.

Ignorer la recherche dans le cache

L'exemple suivant montre comment ignorer la recherche dans le cache et actualiser le cache. Consultez également cette vidéo sur l'utilisation de la règle SkipCacheLookup.

La condition SkipCacheLookup facultative (si elle est configurée) est définie dans le chemin de la requête. Si la condition est définie sur true, la recherche dans le cache est ignorée et le cache actualisé.

Une utilisation courante de l'actualisation de cache conditionnelle est une condition qui définit un en-tête HTTP spécifique amenant la condition à être définie sur true. Une application cliente scriptée pourrait être configurée pour envoyer périodiquement une requête avec l'en-tête HTTP approprié, provoquant explicitement l'actualisation du cache de réponse.

Par exemple, imaginons un appel à une API à l'URL suivante :

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

Imaginons maintenant que la règle ResponseCache suivante soit configurée sur ce proxy. Notez que la condition de contournement du cache est définie sur 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>

Pour en savoir plus sur les conditions, consultez la page Variables de flux et conditions.

Documentation de référence des éléments

La documentation de référence des éléments décrit les éléments et les attributs de la règle.

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

Attributs <ResponseCache>

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

Le tableau suivant décrit les attributs communs à tous les éléments parents des règles :

Attribut	Description	Par défaut	Presence
name	Nom interne de la règle. La valeur de l'attribut name peut contenir des lettres, des chiffres, des espaces, des tirets, des traits de soulignement et des points. Cette valeur ne peut pas dépasser 255 caractères. Vous pouvez également utiliser l'élément <DisplayName> pour ajouter un libellé à la règle dans l'éditeur de proxy de l'interface utilisateur de gestion, en utilisant un nom différent, en langage naturel.	N/A	Obligatoire
continueOnError	Définissez sur false pour afficher une erreur en cas d'échec d'une règle. Il s'agit du comportement attendu pour la plupart des règles. Définissez sur true pour que l'exécution du flux se poursuive même après l'échec d'une règle. Voir également : Les règles d'erreur sont déclenchées UNIQUEMENT en état d'erreur (à propos de continueOnError) Gérer les pannes dans le flux actuel	false	Facultatif
enabled	Définissez sur true pour appliquer la règle. Définissez sur false pour désactiver la règle. La stratégie ne sera pas appliquée, même si elle reste associée à un flux.	true	Facultatif
async	Cet attribut est obsolète.	false	Obsolète

Élément <DisplayName>

Utilisez-le, en plus de l'attribut name, pour appliquer un libellé à la règle dans l'éditeur de proxys de l'interface de gestion en utilisant un nom différent, en langage naturel.

<DisplayName>Policy Display Name</DisplayName>

Par défaut	N/A Si vous omettez cet élément, la valeur de l'attribut name de la règle est utilisée.
Presence	Facultatif
Type	Chaîne

Élément <CacheKey>

Configure un pointeur unique vers un élément de données stocké dans le cache.

Les clés de cache sont limitées à une taille de 2 Ko.

Remarque : Vous pouvez étendre davantage la clé de cache configurée ici à l'aide des valeurs des en-têtes de réponse. Pour en savoir plus, consultez la section Configurer une clé de cache.

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

Valeur par défaut :	N/A
Présence :	Obligatoire
Type :	N/A

<CacheKey> crée le nom de chaque élément de données stocké dans le cache. La clé est souvent définie à l'aide d'une valeur provenant d'en-têtes d'entités ou de paramètres de requête. Dans ce cas, l'attribut "ref" de l'élément spécifie une variable contenant la valeur de la clé.

Au moment de l'exécution, les valeurs <KeyFragment> sont précédées de la valeur de l'élément <Scope> ou de la valeur <Prefix>. Par exemple, les résultats suivants génèrent une clé de cache UserToken__apiAccessToken__<value_of_client_id> :

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

Vous utilisez conjointement l'élément <CacheKey> avec <Prefix> et <Scope>. Pour en savoir plus, consultez la page Utiliser des clés de cache.

Élément <CacheLookupTimeoutInSeconds>

Indique le nombre de secondes après lequel une recherche dans le cache ayant échoué est considérée comme un défaut de cache. Si cela se produit, le flux reprend le long du chemin de défaut de cache.

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

Valeur par défaut :	30
Présence :	Facultative
Type :	Entier

Élément <CacheResource>

Indique le cache où les messages doivent être stockés. Omettez cet élément pour utiliser le cache partagé inclus. Vous devez spécifier un élément CacheResource par nom si vous souhaitez pouvoir effacer de manière administrative les entrées contenues dans le cache. Pour en savoir plus, consultez la section API Caches.

<CacheResource>cache_to_use</CacheResource>

Valeur par défaut :	N/A
Présence :	Facultative
Type :	Chaîne

Élément <CacheKey>/<KeyFragment>

Spécifie une valeur à inclure dans la clé de cache, créant ainsi un espace de noms pour les requêtes correspondantes aux réponses mises en cache.

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

Valeur par défaut :	N/A
Présence :	Facultative
Type :	N/A

Il peut s'agir d'une clé (un nom statique que vous fournissez) ou d'une valeur (un ensemble d'entrées dynamique faisant référence à une variable). Tous les fragments spécifiés combinés (plus le préfixe) sont concaténés pour créer la clé de cache.

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

Vous utilisez conjointement l'élément <KeyFragment> avec <Prefix> et <Scope>. Pour en savoir plus, consultez la page Utiliser des clés de cache.

Attributs

Attribut	Type	Valeur par défaut	Obligatoire	Description
ref	chaîne		Non	Variable à partir de laquelle obtenir la valeur. Ne doit pas être utilisée si cet élément contient une valeur littérale.

Élément <CacheKey>/<Prefix>

Spécifie une valeur à utiliser comme préfixe de clé de cache.

<Prefix>prefix_string</Prefix>

Valeur par défaut :	N/A
Présence :	Facultative
Type :	Chaîne

Utilisez cette valeur à la place de <Scope> lorsque vous souhaitez spécifier votre propre valeur plutôt qu'une valeur énumérée <Scope>. Si cette valeur est définie, <Prefix> ajoute la valeur de la clé de cache pour les entrées écrites dans le cache. La valeur de l'élément <Prefix> remplace celle de l'élément <Scope>.

Vous utilisez conjointement l'élément <Prefix> avec <CacheKey> et <Scope>. Pour en savoir plus, consultez la page Utiliser des clés de cache.

Élément <ExcludeErrorResponse>

Cette règle peut mettre en cache les réponses HTTP associées à n'importe quel code d'état. Cela signifie que les réponses de réussite et d'erreur peuvent être mises en cache, y compris les codes d'état 2xx et 3xx.

Définissez cet élément sur true (valeur par défaut) pour exclure les réponses d'erreur. Définissez-le sur false si vous ne souhaitez pas exclure de la mise en cache les réponses cibles associées à des codes d'état d'erreur HTTP.

Remarque : Les codes d'état compris entre 200 et 205 sont tout de même mis en cache lorsque cet élément est défini sur true. Il s'agit des codes d'état HTTP que Apigee considère comme des codes de "réussite". Vous ne pouvez pas les exclure avec cet élément.

Pour en savoir plus sur les modèles de mise en cache de réponse pour lesquels cet élément est utile, consultez la page Introduction aux antimodèles.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

Valeur par défaut :	true
Présence :	Facultative
Type :	Booléen

Élément <ExpirySettings>

Indique la date d'expiration d'une entrée de cache. Lorsqu'il est présent, l'élément <TimeoutInSeconds> remplace à la fois <TimeOfDay> et <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>

Valeur par défaut :	N/A
Présence :	Obligatoire
Type :	N/A

Élément <ExpirySettings>/<ExpiryDate>

Spécifie la date d'expiration d'une entrée de cache. Utilisez le formulaire mm-dd-yyyy. Lorsqu'il est présent, le frère de cet élément, <TimeoutInSeconds>, remplace <ExpiryDate>.

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

Valeur par défaut :	N/A
Présence :	Facultative
Type :	Chaîne

Attributs

<ExpiryDate ref="" />

Attribut	Description	Valeur par défaut	Presence	Type
ref	Variable à partir de laquelle obtenir la valeur. Ne doit pas être utilisée si cet élément contient une valeur littérale.	N/A	Facultative	Chaîne

Élément <ExpirySettings>/<TimeOfDay>

Heure de la journée à laquelle une entrée de cache doit expirer. Utilisez le formulaire hh:mm:ss. Lorsqu'il est présent, le frère de cet élément, <TimeoutInSeconds>, remplace <TimeOfDay>.

Saisissez l'heure de la journée au format HH:mm:ss, où HH représente l'heure au format 24 heures. Par exemple, 14:30:00 pour 2:30 dans l'après-midi.

Pour l'heure de la journée, les paramètres régionaux et le fuseau horaire par défaut varient en fonction de l'emplacement où est exécuté le code (non connu lors de la configuration de la règle).

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

Valeur par défaut :	N/A
Présence :	Facultative
Type :	Chaîne

Attributs

Attribut	Description	Valeur par défaut	Presence	Type
ref	Variable avec la valeur de délai d'expiration	N/A	Facultative	Chaîne

Élément <ExpirySettings>/<TimeoutInSec>

Remarque : Obsolète. Utilisez l'élément TimeoutInSeconds. Si les éléments TimeoutInSec et TimeoutInSeconds sont présents, Apigee utilise TimeoutInSeconds.

Durée en secondes après laquelle une entrée de cache doit expirer.

Élément <ExpirySettings>/<TimeoutInSeconds>

Durée en secondes après laquelle une entrée de cache doit expirer. Lorsqu'il est présent, cet élément remplace ses frères, <TimeOfDay> et <ExpiryDate>.

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

Remarque : Indiquez une valeur de délai d'expiration par défaut à utiliser si la valeur "ref" ne reçoit pas de valeur de la variable duration_variable.

Valeur par défaut :	N/A
Présence :	Facultative
Type :	Chaîne

Attributs

Attribut	Description	Valeur par défaut	Presence	Type
ref	Variable avec la valeur du délai d'inactivité	ND	Facultative	Chaîne

Élément <Scope>

Énumération permettant de créer un préfixe pour une clé de cache lorsqu'un élément <Prefix> n'est pas fourni dans l'élément <CacheKey>.

<Scope>scope_enumeration</Scope>

Valeur par défaut :	"Exclusive"
Présence :	Facultative
Type :	Chaîne

Le paramètre <Scope> détermine une clé de cache précédée selon la valeur <Scope>. Par exemple, une clé de cache se présente sous la forme suivante lorsque le champ d'application est défini sur Exclusive : orgName__envName__apiProxyName__deployedRevisionNumber__proxy|TargetName__ [ serializedCacheKey ].

Si un élément <Prefix> figure dans <CacheKey>, il remplace la valeur de l'élément <Scope>. Les valeurs valides incluent les énumérations ci-dessous.

Vous utilisez conjointement l'élément <Scope> avec <CacheKey> et <Prefix>. Pour en savoir plus, consultez la page Utiliser des clés de cache.

Valeurs acceptables

Valeur du champ d'application	Description
Global	La clé de cache est partagée entre tous les proxys d'API déployés dans l'environnement. La clé de cache prend un préfixe au format orgName __ envName. Si vous définissez une entrée <CacheKey> avec l'apiAccessToken <KeyFragment> et un champ d'application <Global>, chaque entrée est stockée en tant que orgName__envName__apiAccessToken, suivie de la valeur sérialisée du jeton d'accès. Pour un proxy d'API déployé dans un environnement appelé "test" dans une organisation appelée "apifactory", les jetons d'accès sont stockés sous la clé de cache suivante : apifactory__test__apiAccessToken.
Application	Le nom du proxy d'API est utilisé comme préfixe. La clé de cache prend un préfixe au format orgName__envName__apiProxyName.
Proxy	La configuration ProxyEndpoint est utilisée comme préfixe. La clé de cache prend un préfixe au format orgName__envName__apiProxyName__deployedRevisionNumber__proxyEndpointName.
Target	La configuration TargetEndpoint est utilisée comme préfixe. La clé de cache prend un préfixe au format orgName__envName__apiProxyName__deployedRevisionNumber__targetEndpointName.
Exclusive	Valeur par défaut. C'est la plus spécifique et présente donc un risque minimal de conflits d'espaces de noms dans un cache donné. Le préfixe prend l'une des deux formes suivantes : Si la règle est associée au flux ProxyEndpoint, le préfixe prend la forme ApiProxyName_ProxyEndpointName. Si la règle est associée à TargetEndpoint, le préfixe prend le format ApiProxyName_TargetName. La clé de cache prend un préfixe au format orgName__envName__apiProxyName__deployedRevisionNumber__proxyNameITargetName. Par exemple, la chaîne complète peut ressembler à ceci : apifactory__test__weatherapi__16__default__apiAccessToken .

Élément <SkipCacheLookup>

Définit une expression qui, si elle est définie sur true au moment de l'exécution, spécifie que la recherche dans le cache doit être ignorée et le cache actualisé. Consultez également la vidéo Utiliser la règle ResponseCache sur l'utilisation de SkipCacheLookup.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

Valeur par défaut :	N/A
Présence :	Facultative
Type :	Chaîne

À partir de l'exemple suivant, si la variable de contournement est définie sur true dans un en-tête entrant, la recherche dans le cache est ignorée et le cache est actualisé.

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

Élément <SkipCachePopulation>

Définit une expression qui, si elle est définie sur true au moment de l'exécution, spécifie qu'une écriture dans le cache doit être ignorée. Consultez également cette vidéo sur l'utilisation de SkipCachePopulation.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

Valeur par défaut :	N/A
Présence :	Facultative
Type :	Chaîne

Par exemple, ce qui suit ignore l'écriture dans le cache si le code d'état de la réponse est supérieur ou égal à 400 :

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

Élément <UseAcceptHeader>

Définissez cet élément sur true pour ajouter à la clé de cache d'une entrée de cache de réponse des valeurs issues des en-têtes Accept de la réponse.

Apigee utilise les en-têtes de requête Accept, Accept-Encoding, Accept-Language et Accept-Charset lors du calcul de la clé de cache. Cette approche empêche un client d'obtenir un type de contenu qu'il n'a pas demandé.

Par exemple, déterminez si deux requêtes proviennent de la même URL, où la première requête accepte gzip, mais pas la seconde. La première requête est mise en cache et l'entrée mise en cache est (probablement) une réponse compressée avec gzip. La seconde requête lit la valeur mise en cache et peut renvoyer une entrée compressée avec gzip à un client qui ne parvient pas à lire le format gzip.

Pour en savoir plus, consultez la section Configurer une clé de cache.

<UseAcceptHeader>false</UseAcceptHeader>

Valeur par défaut :	false
Présence :	Facultative
Type :	Booléen

Élément <UseResponseCacheHeaders>

Définissez cet élément sur true pour que les en-têtes de réponse HTTP soient pris en compte lors de la définition de la valeur TTL (Time To Live) de la réponse dans le cache. Lorsque la valeur est true, Apigee prend en compte les valeurs des en-têtes de réponse suivants en comparant les valeurs à celles définies par <ExpirySettings> lors de la configuration de la valeur TTL :

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

Pour en savoir plus, consultez la section Définir le délai d'expiration des entrées de cache.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

Valeur par défaut :	false
Présence :	Facultative
Type :	Booléen

Remarques sur l'utilisation

La taille maximale de chaque objet mis en cache est de 256 ko. (Pour en savoir plus sur la manière dont Apigee traite le cache, consultez la page Composants internes du cache.)

Grâce à la configuration de la règle ResponseCache, Apigee peut inclure des en-têtes de réponse HTTP lors de la définition du délai d'expiration des entrées de cache et des clés de cache. Cette section explique comment utiliser la règle avec des en-têtes pour gérer le délai d'expiration du cache et les clés de cache.

Pour en savoir plus sur la manière dont Apigee gère les en-têtes de réponse avec la règle ResponseCache, consultez la section Compatibilité avec les en-têtes de réponse HTTP.

Remarque : Pour d'autres suggestions de bonnes pratiques liées à la règle ResponseCache, consultez la section Bonnes pratiques de conception et de développement d'un proxy d'API.

Définir le délai d'expiration des entrées de cache

Comme pour la règle PopulateCache, vous pouvez définir l'expiration d'une entrée de cache de réponse (c'est-à-dire sa durée de vie) à l'aide de l'élément <ExpirySettings>. Dans la règle ResponseCache, vous pouvez également indiquer à Apigee de prendre en compte les en-têtes de réponse lorsqu'ils sont présents.

Pour utiliser les en-têtes de réponse, définissez la valeur de l'élément <UseResponseCacheHeaders> sur true. Du fait de ce paramètre, Apigee examine les en-têtes de réponse, les compare à la valeur définie par <ExpirySettings>, puis utilise la valeur la plus basse entre les deux. Lorsqu'il examine les en-têtes de réponse, Apigee choisit la valeur disponible comme décrit ci-dessous :

Par exemple, imaginons qu'une réponse soit mise en cache avec les valeurs suivantes :

• Aucune valeur Cache-Control s-maxage
• Une valeur de Cache-Control max-age
• Une date Expires dans trois jours
• Une valeur <ExpirySettings> TimeoutInSeconds de 600

Dans ce cas, la valeur Cache-Control max-age serait utilisée pour la valeur TTL, car elle est inférieure à la valeur <ExpirySettings> et parce qu'il n'y a pas de valeur Cache-Control s-maxage (qui l'emporte sur max-age).

Configurer une clé de cache

Comme pour les règles de cache à usage général, telles que la règle PopulateCache, avec la règle ResponseCache, vous utilisez les éléments <CacheKey> et <Scope> afin de configurer la création de clés de cache pour les entrées de cache. Avec la règle ResponseCache, vous pouvez également rendre les clés de cache plus significatives en ajoutant des en-têtes Accept de réponse aux valeurs de clé.

Pour obtenir des informations générales sur la configuration des clés de cache, consultez la section Utiliser des clés de cache. Pour en savoir plus sur l'utilisation des en-têtes "Accept", consultez la page <UseAcceptHeader>.

À propos du chiffrement du cache

Apigee et Apigee hybrid (version 1.4 et ultérieure) : les données de cache et de KVM sont toujours chiffrées.

Variables de flux

Les variables de flux prédéfinies suivantes sont renseignées lorsqu'une règle ResponseCache est exécutée. Pour en savoir plus sur les variables de flux, consultez la documentation de référence sur les variables de flux.

Variables	Type	Autorisation	Description
responsecache.{policy_name}.cachename	Chaîne	En lecture seule	Renvoie le cache utilisé dans la règle.
responsecache.{policy_name}.cachekey	Chaîne	En lecture seule	Renvoie la clé utilisée.
responsecache.{policy_name}.cachehit	Booléen	En lecture seule	La valeur est "True" si l'exécution de la règle a réussi.
responsecache.{policy_name}.invalidentry	Booléen	En lecture seule	La valeur est "True" si l'entrée de cache n'est pas valide

Codes d'erreur

Cette section décrit les messages d'erreur et les variables de flux définies lorsque cette règle déclenche une erreur. Ces informations sont importantes si vous développez des règles de défaillance pour un proxy. Pour en savoir plus, consultez les pages Ce que vous devez savoir à propos des erreurs liées aux règles et Gérer les pannes.

Préfixe de code d'erreur

ND

Erreurs d'exécution

Cette règle ne génère aucune erreur d'exécution.

Erreurs de déploiement

Ces erreurs peuvent se produire lorsque vous déployez un proxy contenant cette règle.

Conseil : Vous avez besoin d'aide pour résoudre une erreur ? Cliquez sur dans la colonne "Corriger" pour obtenir des informations de dépannage détaillées.

Nom de l'erreur	Cause	Corriger
InvalidTimeout	Si l'élément <CacheLookupTimeoutInSeconds> d'une règle ResponseCache est défini sur un nombre négatif, le déploiement du proxy d'API échoue.
InvalidCacheResourceReference	Cette erreur se produit si l'élément <CacheResource> d'une règle ResponseCache est défini sur un nom qui n'existe pas dans l'environnement où le proxy d'API est déployé.
ResponseCacheStepAttachmentNotAllowedReq	Cette erreur se produit si la même règle ResponseCache est associée à plusieurs chemins de requête dans tous les flux d'un proxy d'API.
ResponseCacheStepAttachmentNotAllowedResp	Cette erreur se produit si la même règle ResponseCache est associée à plusieurs chemins de réponse dans les flux d'un proxy d'API.
InvalidMessagePatternForErrorCode	Cette erreur se produit si les éléments <SkipCacheLookup> ou <SkipCachePopulation> d'une règle ResponseCache contiennent une condition non valide.
CacheNotFound	Cette erreur se produit si le cache spécifique mentionné dans le message d'erreur n'a pas été créé sur un composant du processeur de messages spécifique.

Variables de panne

ND

Exemple de réponse d'erreur

ND

Schéma

Chaque type de règle est défini par un schéma XML (.xsd). Pour référence, des schémas de règles sont disponibles sur GitHub.