Política ResponseCache

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Esta política almacena en caché los datos de un recurso de backend, lo que reduce el número de solicitudes al recurso. Cuando las aplicaciones hacen solicitudes al mismo URI, puedes usar esta política para devolver respuestas almacenadas en caché en lugar de reenviar esas solicitudes al servidor backend. La política ResponseCache puede mejorar el rendimiento de tu API reduciendo la latencia y el tráfico de red.

Esta política es una política extensible y su uso puede tener implicaciones en cuanto a costes o utilización, en función de tu licencia de Apigee. Para obtener información sobre los tipos de políticas y las implicaciones de uso, consulta Tipos de políticas.

Es probable que ResponseCache te resulte más útil cuando los datos de backend que usa tu API se actualicen solo periódicamente. Por ejemplo, supongamos que tienes una API que expone datos de informes meteorológicos que solo se actualizan cada diez minutos. Si usas ResponseCache para devolver respuestas almacenadas en caché entre actualizaciones, puedes reducir el número de solicitudes que llegan al backend. También se reduce el número de saltos de red.

Para el almacenamiento en caché a corto plazo de uso general, te recomendamos que uses la política PopulateCache. Esta política se usa junto con la política LookupCache (para leer entradas de caché) y la política InvalidateCache (para invalidar entradas).

Echa un vistazo al siguiente vídeo para conocer los aspectos básicos de la política de caché de respuestas.

Nota: Para consultar una descripción de los antipatrones de la política Response Cache, consulta Introducción a los antipatrones.

Nota: Solo puedes adjuntar esta política una vez en el flujo de solicitudes proxy y otra en el flujo de respuestas. No puedes usar la política ResponseCache en un flujo compartido.

Para ver un videotutorial sobre cómo usar la política, consulta Tutorial: Implementing Response Caching within Edge. Consulta también la sección Códigos de error que aparece más abajo.

Ejemplos

Caché de 10 minutos

En este ejemplo se muestra cómo mantener las respuestas almacenadas en caché durante 10 minutos.

Supongamos que tienes una API en la siguiente URL:

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

Estás usando el parámetro de consulta w como clave de caché. Apigee comprueba el valor del parámetro de consulta w cada vez que se recibe una solicitud. Si hay una respuesta válida (es decir, que no ha caducado) en la caché, se devuelve el mensaje de respuesta almacenado en caché al cliente que ha enviado la solicitud.

Ahora, supongamos que tiene una política ResponseCache configurada de la siguiente manera.

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

La primera vez que el proxy de API recibe un mensaje de solicitud para la siguiente URL, la respuesta se almacena en caché. En la segunda solicitud en un plazo de 10 minutos, se realiza una búsqueda en la caché. La respuesta almacenada en caché se devuelve a la aplicación sin que se reenvíe ninguna solicitud al servicio backend.

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

Nota: Los encabezados HTTP y los parámetros de consulta se rellenan automáticamente como variables cuando se recibe una solicitud. Cualquier encabezado HTTP está disponible como request.header.{header_name}, por ejemplo, request.header.user-agent. Cualquier parámetro de consulta está disponible como request.queryparam.{queryparam_name}, por ejemplo, request.queryparam.action.

Omitir la búsqueda en caché

En el siguiente ejemplo se muestra cómo omitir la búsqueda en la caché y actualizarla. Consulta también este vídeo sobre el uso de SkipCacheLookup.

La condición SkipCacheLookup opcional (si se ha configurado) se evalúa en la ruta de la solicitud. Si la condición se evalúa como verdadera, se omite la búsqueda en la caché y se actualiza.

Un uso habitual de la actualización condicional de la caché es una condición que define un encabezado HTTP específico que hace que la condición se evalúe como verdadera. Una aplicación cliente basada en secuencias de comandos se puede configurar para que envíe periódicamente una solicitud con el encabezado HTTP adecuado, lo que provocará explícitamente que se actualice la caché de respuestas.

Por ejemplo, supongamos que se llama a una API en la siguiente URL:

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

Ahora, supongamos que se ha configurado la siguiente política ResponseCache en ese proxy. Ten en cuenta que la condición bypass-cache se ha definido como 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>

Para obtener más información sobre las condiciones, consulta Variables y condiciones de flujo.

Referencia de elemento

En la referencia de elementos se describen los elementos y atributos de la política.

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

Atributos de <ResponseCache>

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

En la siguiente tabla se describen los atributos que son comunes a todos los elementos superiores de la política:

Atributo	Descripción	Predeterminado	Presencia
name	El nombre interno de la política. El valor del atributo name puede contener letras, números, espacios, guiones, guiones bajos y puntos. Este valor no puede superar los 255 caracteres. Opcionalmente, usa el elemento <DisplayName> para etiquetar la política en el editor de proxy de la interfaz de gestión con un nombre diferente en lenguaje natural.	N/A	Obligatorio
continueOnError	Asigna el valor false para devolver un error cuando falle una política. Este es el comportamiento esperado de la mayoría de las políticas. Asigna el valor true para que la ejecución del flujo continúe incluso después de que falle una política. Consulta también: Las reglas de errores solo se activan cuando hay un error (sobre continueOnError) Gestionar fallos en el flujo actual	falso	Opcional
enabled	Asigna el valor true para aplicar la política. Selecciona false para desactivar la política. La política no se aplicará aunque siga adjunta a un flujo.	true	Opcional
async	Este atributo está obsoleto.	falso	Obsoleto

Elemento <DisplayName>

Úsalo junto con el atributo name para etiquetar la política en el editor de proxy de la interfaz de gestión con un nombre diferente en lenguaje natural.

<DisplayName>Policy Display Name</DisplayName>

Predeterminado	N/A Si omite este elemento, se usará el valor del atributo name de la política.
Presencia	Opcional
Tipo	Cadena

Elemento <CacheKey>

Configura un puntero único a un fragmento de datos almacenado en la caché.

Las claves de caché tienen un tamaño máximo de 2 KB.

Nota: Puede aumentar aún más la clave de caché configurada aquí usando valores de los encabezados de respuesta. Para obtener más información, consulta Configurar una clave de caché.

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

Valor predeterminado:	N/A
Presencia:	Obligatorio
Tipo:	N/A

<CacheKey> crea el nombre de cada dato almacenado en la caché. La clave se suele definir con un valor de los encabezados de la entidad o de los parámetros de consulta. En esos casos, el atributo ref del elemento especificaría una variable que contiene el valor de la clave.

En el tiempo de ejecución, los valores de <KeyFragment> se anteponen al valor del elemento <Scope> o al valor de <Prefix>. Por ejemplo, lo siguiente da como resultado una clave de caché de UserToken__apiAccessToken__<value_of_client_id>:

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

Para ello, usa el elemento <CacheKey> junto con <Prefix> y <Scope>. Para obtener más información, consulta el artículo Trabajar con claves de caché.

Elemento <CacheLookupTimeoutInSeconds>

Especifica el número de segundos tras los cuales se considerará que no se ha encontrado el elemento en la caché. Si esto ocurre, el flujo se reanuda por la ruta de no encontrado en caché.

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

Valor predeterminado:	30
Presencia:	Opcional
Tipo:	Entero

Elemento <CacheResource>

Especifica la caché en la que se deben almacenar los mensajes. Omite este elemento para usar la caché compartida incluida. Debes especificar un CacheResource por su nombre si quieres poder borrar administrativamente las entradas contenidas en la caché. Para obtener más información, consulta la API Caches.

<CacheResource>cache_to_use</CacheResource>

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	Cadena

Elemento <CacheKey>/<KeyFragment>

Especifica un valor que se debe incluir en la clave de caché, lo que crea un espacio de nombres para que las solicitudes coincidan con las respuestas almacenadas en caché.

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

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	N/A

Puede ser una clave (un nombre estático que proporcione) o un valor (una entrada dinámica definida por una referencia a una variable). Todos los fragmentos especificados combinados (más el prefijo) se concatenan para crear la clave de caché.

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

Para ello, usa el elemento <KeyFragment> junto con <Prefix> y <Scope>. Para obtener más información, consulta el artículo Trabajar con claves de caché.

Atributos

Atributo	Tipo	Predeterminado	Obligatorio	Descripción
ref	cadena		No	La variable de la que se va a obtener el valor. No debe usarse si este elemento contiene un valor literal.

Elemento <CacheKey>/<Prefix>

Especifica un valor que se usará como prefijo de clave de caché.

<Prefix>prefix_string</Prefix>

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	Cadena

Use este valor en lugar de <Scope> cuando quiera especificar su propio valor en lugar de un valor enumerado de <Scope>. Si se define, <Prefix> añade el valor de la clave de caché a las entradas escritas en la caché. El valor de un elemento <Prefix> anula el valor de un elemento <Scope>.

Para ello, usa el elemento <Prefix> junto con <CacheKey> y <Scope>. Para obtener más información, consulta el artículo Trabajar con claves de caché.

Elemento <ExcludeErrorResponse>

Esta política puede almacenar en caché respuestas HTTP con cualquier código de estado. Esto significa que tanto las respuestas correctas como las de error se pueden almacenar en caché, incluidos los códigos de estado 2xx y 3xx.

Defina este elemento como true (valor predeterminado) para excluir las respuestas de error. Defínelo como false si no quieres excluir las respuestas de destino de la caché con códigos de estado de error HTTP.

Nota: Los códigos de estado del 200 al 205 se siguen almacenando en caché cuando este elemento se define como true. Estos son los códigos de estado HTTP que Apigee considera códigos de "éxito" y no se pueden excluir con este elemento.

Para ver un debate sobre los patrones de caché de respuestas en los que este elemento es útil, consulta Introducción a los antipatrones.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

Valor predeterminado:	true
Presencia:	Opcional
Tipo:	Booleano

Elemento <ExpirySettings>

Especifica cuándo debe caducar una entrada de caché. Si está presente, <TimeoutInSeconds> sustituye a <TimeOfDay> y <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>

Valor predeterminado:	N/A
Presencia:	Obligatorio
Tipo:	N/A

Elemento <ExpirySettings>/<ExpiryDate>

Especifica la fecha en la que debe caducar una entrada de caché. Usa el formulario mm-dd-yyyy. Si está presente, el elemento del mismo nivel <TimeoutInSeconds> anula <ExpiryDate>.

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

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	Cadena

Atributos

<ExpiryDate ref="" />

Atributo	Descripción	Predeterminado	Presencia	Tipo
ref	La variable de la que se va a obtener el valor. No debe usarse si este elemento contiene un valor literal.	N/A	Opcional	Cadena

Elemento <ExpirySettings>/<TimeOfDay>

La hora del día a la que debe caducar una entrada de caché. Usa el formulario hh:mm:ss . Si está presente, el elemento del mismo nivel <TimeoutInSeconds> anula <TimeOfDay>.

Introduce la hora del día en formato HH:mm:ss, donde HH representa la hora en un reloj de 24 horas. Por ejemplo, 14:30:00 para las 2:30 de la tarde.

En cuanto a la hora del día, la configuración regional y la zona horaria predeterminadas variarán en función de dónde se ejecute el código (que no se puede saber al configurar la política).

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

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	Cadena

Atributos

Atributo	Descripción	Predeterminado	Presencia	Tipo
ref	Variable con el valor del tiempo de vencimiento.	N/A	Opcional	Cadena

Elemento <ExpirySettings>/<TimeoutInSec>

Nota: Este método está obsoleto. Usa TimeoutInSeconds. Si se incluyen los elementos TimeoutInSec y TimeoutInSeconds, Apigee usa TimeoutInSeconds.

Número de segundos tras los cuales debe caducar una entrada de caché.

Elemento <ExpirySettings>/<TimeoutInSeconds>

Número de segundos tras los cuales debe caducar una entrada de caché. Si está presente, este elemento anula sus elementos del mismo nivel, <TimeOfDay> y <ExpiryDate>.

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

Nota: Proporciona un valor de tiempo de espera predeterminado que se usará si la referencia no recibe un valor de duration_variable.

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	Cadena

Atributos

Atributo	Descripción	Predeterminado	Presencia	Tipo
ref	Variable con el valor de tiempo de espera.	N/A	Opcional	Cadena

Elemento <Scope>

Enumeración que se usa para crear un prefijo para una clave de caché cuando no se proporciona un elemento <Prefix> en el elemento <CacheKey>.

<Scope>scope_enumeration</Scope>

Valor predeterminado:	"Exclusivo"
Presencia:	Opcional
Tipo:	Cadena

El ajuste <Scope> determina una clave de caché que se antepone según el valor de <Scope>. Por ejemplo, una clave de caché tendría el siguiente formato cuando el ámbito se definiera como Exclusive: orgName__envName__apiProxyName__proxy|TargetName__ [ serializedCacheKey ].

Si hay un elemento <Prefix> en <CacheKey>, este sustituye al valor del elemento <Scope>. Los valores válidos incluyen las enumeraciones que se indican a continuación.

Para ello, usa el elemento <Scope> junto con <CacheKey> y <Prefix>. Para obtener más información, consulta el artículo Trabajar con claves de caché.

Valores aceptables

Valor de alcance	Descripción
Global	La clave de caché se comparte entre todos los proxies de API implementados en el entorno. La clave de caché se antepone con el formato nombreOrganización __ nombreEntorno __. Si define una entrada <CacheKey> con <KeyFragment> apiAccessToken y un <Global> scope, cada entrada se almacena como orgName__envName__apiAccessToken, seguido del valor serializado del token de acceso. En el caso de un proxy de API implementado en un entorno llamado "test" de una organización llamada "apifactory", los tokens de acceso se almacenarían en la siguiente clave de caché: apifactory__test__apiAccessToken.
Application	El nombre del proxy de API se usa como prefijo. La clave de caché se antepone con el formato orgName__envName__apiProxyName.
Proxy	La configuración de ProxyEndpoint se usa como prefijo. La clave de caché se antepone con el formato orgName__envName__apiProxyName__proxyEndpointName .
Target	La configuración de TargetEndpoint se usa como prefijo. Clave de caché antepuesta con el formato orgName__envName__apiProxyName__targetEndpointName .
Exclusive	Predeterminado. Es la más específica y, por lo tanto, presenta un riesgo mínimo de colisiones de espacios de nombres en una caché determinada. El prefijo puede tener dos formas: Si la política se adjunta al flujo ProxyEndpoint, el prefijo tendrá el formato ApiProxyName_ProxyEndpointName. Si la política se adjunta en TargetEndpoint, el prefijo tiene el formato ApiProxyName_TargetName. Clave de caché con el prefijo en el formato orgName__envName__apiProxyName__proxyNameITargetName Por ejemplo, la cadena completa podría tener este aspecto: apifactory__test__weatherapi__default__apiAccessToken .

Elemento <SkipCacheLookup>

Define una expresión que, si se evalúa como verdadera en el tiempo de ejecución, especifica que se debe omitir la búsqueda en la caché y que se debe actualizar la caché. Consulta también el vídeo sobre la política ResponseCache sobre el uso de SkipCacheLookup.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	Cadena

En el siguiente ejemplo, si la variable bypass-cache se define como true en un encabezado entrante, se omite la búsqueda en la caché y se actualiza la caché.

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

Elemento <SkipCachePopulation>

Define una expresión que, si se evalúa como verdadera en el tiempo de ejecución, especifica que se debe omitir una escritura en la caché. Consulta también este vídeo sobre el uso de SkipCachePopulation.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

Valor predeterminado:	N/A
Presencia:	Opcional
Tipo:	Cadena

Por ejemplo, se omitiría la escritura en caché si el código de estado de la respuesta fuera 400 o superior:

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

Elemento <UseAcceptHeader>

Asigna el valor true para que la clave de caché de una entrada de caché de respuesta se añada con los valores de los encabezados Accept de la respuesta.

Apigee usa los encabezados de solicitud Accept, Accept-Encoding, Accept-Language y Accept-Charset al calcular la clave de caché. De esta forma, se evita que un cliente obtenga un tipo de contenido multimedia que no ha solicitado.

Por ejemplo, supongamos que se reciben dos solicitudes de la misma URL, donde la primera acepta gzip y la segunda no. La primera solicitud se almacenará en caché y la entrada almacenada en caché (probablemente) será una respuesta comprimida con gzip. La segunda solicitud leerá el valor almacenado en caché y, a continuación, puede devolver una entrada comprimida con gzip a un cliente que no pueda leer gzip.

Consulta más información sobre cómo configurar una clave de caché.

<UseAcceptHeader>false</UseAcceptHeader>

Valor predeterminado:	falso
Presencia:	Opcional
Tipo:	Booleano

Elemento <UseResponseCacheHeaders>

Se define como true para que se tengan en cuenta los encabezados de respuesta HTTP al definir el tiempo de vida (TTL) de la respuesta en la caché. Si es true, Apigee tiene en cuenta los valores de los siguientes encabezados de respuesta y los compara con los valores definidos por <ExpirySettings> al definir el tiempo de vida:

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

Consulta más información en el artículo Configurar la caducidad de las entradas de caché.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

Valor predeterminado:	falso
Presencia:	Opcional
Tipo:	Booleano

Notas de uso

El tamaño máximo de cada objeto almacenado en caché es de 256 KB. Para obtener información detallada sobre cómo procesa Apigee la caché, consulta Interno de la caché.

Mediante la configuración de la política ResponseCache, puede hacer que Apigee incluya encabezados de respuesta HTTP al definir la caducidad de las entradas de caché y las claves de caché. En esta sección se describe cómo puedes usar la política con encabezados para gestionar la caducidad de la caché y las claves de caché.

Para obtener más información sobre cómo gestiona Apigee los encabezados de respuesta con la política ResponseCache, consulta Compatibilidad con encabezados de respuesta HTTP.

Nota: Para ver otras sugerencias de prácticas recomendadas relacionadas con la política ResponseCache, consulta las prácticas recomendadas para el diseño y el desarrollo de proxies de API.

Configurar la caducidad de una entrada de caché

Al igual que con la política PopulateCache, puedes definir la caducidad de una entrada de caché de respuesta (su tiempo de vida) mediante el elemento <ExpirySettings>. En la política ResponseCache, también puede hacer que Apigee tenga en cuenta los encabezados de respuesta cuando estén presentes.

Para usar encabezados de respuesta, asigna el valor true al elemento <UseResponseCacheHeaders>. Este ajuste hace que Apigee tenga en cuenta los encabezados de respuesta, los compare con el valor definido por <ExpirySettings> y, a continuación, use el valor más bajo de los dos. Al tener en cuenta los encabezados de respuesta, Apigee elige el valor disponible tal como se describe a continuación:

Por ejemplo, supongamos que una respuesta se almacena en caché con los siguientes valores:

• No hay ningún valor de Cache-Control s-maxage
• Un valor de Cache-Control max-age de 300
• Una fecha Expires dentro de tres días
• Un valor de <ExpirySettings> TimeoutInSeconds de 600.

En este caso, se usaría el valor Cache-Control max-age para el TTL porque es inferior al valor <ExpirySettings> y porque no hay ningún valor Cache-Control s-maxage (que tiene prioridad sobre max-age).

Configurar una clave de caché

Al igual que con las políticas de caché de uso general, como la política PopulateCache, con ResponseCache se usan los elementos <CacheKey> y <Scope> para configurar la creación de claves de caché de las entradas de caché. Con ResponseCache, también puedes hacer que las claves de caché sean más significativas añadiendo los encabezados Accept de la respuesta a los valores de las claves.

Para obtener información general sobre cómo configurar claves de caché, consulta el artículo Trabajar con claves de caché. Para obtener información sobre cómo usar los encabezados Accept, consulta <UseAcceptHeader>.

Acerca del cifrado de caché

Apigee y Apigee hybrid (versión 1.4 y posteriores): los datos de caché y KVM siempre están cifrados.

Variables de flujo

Las siguientes variables de flujo predefinidas se rellenan cuando se ejecuta una política ResponseCache. Para obtener más información sobre las variables de flujo, consulta la referencia de variables de flujo.

Variables	Tipo	Permiso	Descripción
responsecache.{policy_name}.cachename	Cadena	Solo lectura	Devuelve la caché usada en la política.
responsecache.{policy_name}.cachekey	Cadena	Solo lectura	Devuelve la clave usada
responsecache.{policy_name}.cachehit	Booleano	Solo lectura	True si la ejecución de la política se ha realizado correctamente.
responsecache.{policy_name}.invalidentry	Booleano	Solo lectura	Devuelve true si la entrada de caché no es válida.

Códigos de error

En esta sección se describen los mensajes de error y las variables de flujo que se definen cuando esta política activa un error. Es importante que conozcas esta información si vas a desarrollar reglas de errores para un proxy. Para obtener más información, consulta Qué debes saber sobre los errores de políticas y Cómo gestionar los fallos.

Prefijo del código de error

N/A

Errores de tiempo de ejecución

Esta política no genera ningún error de tiempo de ejecución.

Errores de implementación

Estos errores pueden producirse al implementar un proxy que contenga esta política.

Nota: ¿Necesitas ayuda para resolver un error? En la columna Solución, haz clic en para obtener información detallada sobre cómo solucionar el problema.

Nombre del error	Causa	Solucionar
InvalidTimeout	Si el elemento <CacheLookupTimeoutInSeconds> de la política ResponseCache se asigna a un número negativo, se producirá un error en la implementación del proxy de API.
InvalidCacheResourceReference	Este error se produce si el elemento <CacheResource> de una política ResponseCache se asigna a un nombre que no existe en el entorno en el que se está implementando el proxy de API.
ResponseCacheStepAttachmentNotAllowedReq	Este error se produce si la misma política ResponseCache se adjunta a varias rutas de solicitud en cualquier flujo de un proxy de API.
ResponseCacheStepAttachmentNotAllowedResp	Este error se produce si la misma política ResponseCache se adjunta a varias rutas de respuesta en cualquier flujo de un proxy de API.
InvalidMessagePatternForErrorCode	Este error se produce si el elemento <SkipCacheLookup> o el elemento <SkipCachePopulation> de una política ResponseCache contiene una condición no válida.
CacheNotFound	Este error se produce si la caché específica mencionada en el mensaje de error no se ha creado en un componente Message Processor específico.

Variables de error

N/A

Ejemplo de respuesta de error

N/A

Esquema

Cada tipo de política se define mediante un esquema XML (.xsd). Puedes consultar los esquemas de políticas en GitHub.