Règle ResponseCache

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X.
en savoir plus

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.

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 à court terme, pensez à utiliser la règle de remplissage de cache. Cette règle est utilisée avec la règle de consultation de cache (pour la lecture des entrées de cache) et la règle d'invalidation de cache (pour l'invalidation des entrées).

Regardez cette vidéo qui présente la règle de cache de réponse.

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

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 Présence
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.

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.

Présence 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.

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

Facultatif

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

<CacheResource>cache_to_use</CacheResource>

Valeur par défaut :

N/A

Présence :

Facultatif

Type :

Chaîne

Pour en savoir plus sur la configuration des caches, consultez la page Créer et modifier un cache d'environnement.

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

Facultatif

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

Facultatif

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>

Actuellement, cette règle met en cache par défaut les réponses HTTP contenant tout code d'état possible. Cela signifie que les réponses de réussite et d'erreur sont mises en cache. Par exemple, les réponses avec les codes d'état 2xx et 3xx sont mises en cache par défaut.

Définissez cet élément sur true si vous ne souhaitez pas mettre en cache les réponses cibles avec des codes d'état d'erreur HTTP. Seules les réponses comportant des codes d'état de 200 à 205 seront mises en cache si cet élément a la valeur true. Ce sont les seuls codes d'état HTTP que Edge compte comme des codes de "réussite", et vous ne pouvez pas modifier cette association.

Pour en savoir plus sur les formats d'un cache de réponse dans lesquels cet élément est utile, consultez ce post destiné à la communauté.

Remarque : Dans une prochaine version (à déterminer), le paramètre par défaut de cet élément sera remplacé par "true". Consultez les Notes de version d'Apigee pour plus de détails.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

Valeur par défaut :

false

Présence :

Facultatif

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 :

Facultatif

Type :

Chaîne

Attributs

<ExpiryDate ref="" />
Attribut Description Par défaut Présence 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 Facultatif 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). Pour en savoir plus sur la configuration des paramètres régionaux, consultez Créer et modifier un cache d'environnement.

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

Valeur par défaut :

N/A

Présence :

Facultatif

Type :

Chaîne

Attributs

Attribut Description Par défaut Présence Type
ref Variable avec la valeur de délai d'expiration N/A Facultatif Chaîne

Élément <ExpirySettings>/<TimeoutInSec>

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'inactivité par défaut à utiliser si la référence ne reçoit pas de valeur de duration_variable.

Valeur par défaut :

N/A

Présence :

Facultatif

Type :

Chaîne

Attributs

Attribut Description Par défaut Présence Type
ref Variable avec la valeur du délai d'inactivité
N/A
Facultatif 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 :

Facultatif

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 cette vidéo sur l'utilisation de la règle SkipCacheLookup.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

Valeur par défaut :

N/A

Présence :

Facultatif

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 la règle SkipCachePopulation.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

Valeur par défaut :

N/A

Présence :

Facultatif

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.

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

Facultatif

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 c'est le cas, Edge 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 définition de l'heure de vie:

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

Facultatif

Type :

Booléen

Remarques sur l'utilisation

La taille maximale de chaque objet mis en cache est de 256 ko. (Pour plus d'informations sur la manière dont Edge traite le cache, consultez la section Internes du cache.)

Grâce à la configuration dans la stratégie ResponseCache, vous pouvez demander à Edge d'inclure des en-têtes de réponse HTTP lors de la définition de l'expiration de l'entrée 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 plus d'informations sur la façon dont Edge gère les en-têtes de réponse avec la stratégie ResponseCache, voir Prise en charge des en-têtes de réponse HTTP.

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

Comme pour la règle de remplissage du cache, 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 stratégie ResponseCache, vous pouvez également demander à Edge 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. Ce paramètre oblige Edge à prendre en compte les en-têtes de réponse, à les comparer à la valeur définie par <ExpirySettings>, puis à utiliser la valeur la plus basse entre les deux. Lors de l'examen des en-têtes de réponse, Edge choisit la valeur disponible comme décrit dans ce qui suit:

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 de remplissage de cache, 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

Edge pour le cloud public:le cache est chiffré uniquement dans les organisations conformes à la norme PCI et à la loi HIPAA. Le chiffrement de ces organisations est configuré lors de la gestion de leurs comptes.

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.

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

N/A

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.

Nom de l'erreur Cause Solution
InvalidTimeout Si l'élément <CacheLookupTimeoutInSeconds> de la 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 tous 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

N/A

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.