Política ResponseCache

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Esta política coloca em cache os dados de um recurso de back-end, reduzindo o número de pedidos ao recurso. À medida que as apps fazem pedidos ao mesmo URI, pode usar esta política para devolver respostas em cache em vez de encaminhar esses pedidos para o servidor de back-end. A política ResponseCache pode melhorar o desempenho da sua API através da redução da latência e do tráfego de rede.

Esta política é uma política extensível e a utilização desta política pode ter implicações de custo ou utilização, consoante a sua licença do Apigee. Para ver informações sobre os tipos de políticas e as implicações de utilização, consulte Tipos de políticas.

É provável que considere a ResponseCache mais útil quando os dados de back-end usados pela sua API são atualizados apenas periodicamente. Por exemplo, imagine que tem uma API que expõe dados de relatórios meteorológicos atualizados apenas a cada dez minutos. Ao usar ResponseCache para devolver respostas em cache entre atualizações, pode diminuir o número de pedidos que chegam ao back-end. Isto também reduz o número de saltos de rede.

Para o armazenamento em cache a curto prazo de utilização geral, pondere usar a política PopulateCache. Essa política é usada em conjunto com a política LookupCache (para ler entradas da cache) e a política InvalidateCache (para invalidar entradas).

Veja o vídeo seguinte para uma introdução à política de cache de respostas.

Dica: para uma discussão sobre os antipadrões da política de cache de respostas, consulte a Introdução aos antipadrões.

Nota: só pode anexar esta política uma vez no fluxo de pedidos de proxy e uma vez no fluxo de respostas. Não pode usar a política ResponseCache num fluxo partilhado.

Para ver um tutorial em vídeo que mostra como usar a política, consulte o Tutorial: Implementar a colocação em cache de respostas no Edge. Consulte também os códigos de erro abaixo.

Amostras

Cache de 10 minutos

Este exemplo mostra como manter as respostas em cache durante 10 minutos.

Imagine que tem uma API no seguinte URL:

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

Está a usar o parâmetro de consulta w como uma chave de cache. O Apigee verifica o valor do parâmetro de consulta w sempre que é recebido um pedido. Se estiver presente na cache uma resposta válida (ou seja, não expirada), a mensagem de resposta em cache é devolvida ao cliente que fez o pedido.

Agora, imagine que tem uma política ResponseCache configurada da seguinte forma.

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

A primeira vez que o proxy da API recebe uma mensagem de pedido para o seguinte URL, a resposta é colocada em cache. No segundo pedido no prazo de 10 minutos, ocorre uma procura na cache. A resposta em cache é devolvida à app sem que seja encaminhado nenhum pedido para o serviço de back-end.

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

Sugestão: os cabeçalhos HTTP e os parâmetros de consulta são preenchidos automaticamente como variáveis quando é recebido um pedido. Qualquer cabeçalho HTTP está disponível como request.header.{header_name}, por exemplo request.header.user-agent. Qualquer parâmetro de consulta está disponível como request.queryparam.{queryparam_name}, por exemplo request.queryparam.action.

Ignorar pesquisa de cache

O exemplo seguinte mostra como ignorar a pesquisa na cache e atualizar a cache. Consulte também este vídeo sobre a utilização de SkipCacheLookup.

A condição SkipCacheLookup opcional (se configurada) é avaliada no caminho do pedido. Se a condição for avaliada como verdadeira, a pesquisa na cache é ignorada e a cache é atualizada.

Uma utilização comum da atualização da cache condicional é uma condição que define um cabeçalho HTTP específico que faz com que a condição seja avaliada como verdadeira. Uma aplicação cliente com script pode ser configurada para enviar periodicamente um pedido com o cabeçalho HTTP adequado, o que faz com que a cache de respostas seja atualizada explicitamente.

Por exemplo, imagine uma chamada a uma API no seguinte URL:

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

Agora, imagine a seguinte política ResponseCache configurada nesse proxy. Tenha em atenção que a condição bypass-cache está definida como verdadeira.

<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 mais informações sobre as condições, consulte o artigo Variáveis de fluxo e condições.

Referência do elemento

A referência de elementos descreve os elementos e os atributos da 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 <ResponseCache>

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

A tabela seguinte descreve os atributos comuns a todos os elementos principais de políticas:

Atributo	Descrição	Predefinição	Presença
name	O nome interno da política. O valor do atributo name pode conter letras, números, espaços, hífenes, sublinhados e pontos finais. Este valor não pode exceder 255 carateres. Opcionalmente, use o elemento <DisplayName> para etiquetar a política no editor de proxy da IU de gestão com um nome diferente em linguagem natural.	N/A	Obrigatória
continueOnError	Definido como false para devolver um erro quando uma política falha. Este comportamento é o esperado para a maioria das políticas. Definido como true para que a execução do fluxo continue mesmo depois de uma política falhar. Veja também: As regras de falhas são acionadas APENAS num estado de erro (acerca de continueOnError) Processar falhas no fluxo atual	falso	Opcional
enabled	Defina como true para aplicar a política. Defina como false para desativar a política. A política não é aplicada, mesmo que permaneça associada a um fluxo.	verdadeiro	Opcional
async	Este atributo foi descontinuado.	falso	Descontinuado

Elemento <DisplayName>

Use em conjunto com o atributo name para etiquetar a política no editor de proxy da IU de gestão com um nome diferente em linguagem natural.

<DisplayName>Policy Display Name</DisplayName>

Predefinição	N/A Se omitir este elemento, é usado o valor do atributo name da política.
Presença	Opcional
Tipo	String

Elemento <CacheKey>

Configura um ponteiro único para um fragmento de dados armazenado na cache.

As chaves da cache estão limitadas a um tamanho de 2 KB.

Nota: pode aumentar ainda mais a chave da cache configurada aqui usando valores dos cabeçalhos de resposta. Para mais informações, consulte o artigo Configurar uma chave de cache.

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

Predefinição:	N/A
Presença:	Obrigatória
Tipo:	N/A

<CacheKey> cria o nome de cada parte dos dados armazenados na cache. A chave é frequentemente definida através de um valor dos cabeçalhos de entidades ou dos parâmetros de consulta. Nesses casos, o atributo ref do elemento especifica uma variável que contém o valor da chave.

Em tempo de execução, os valores <KeyFragment> são precedidos pelo valor do elemento <Scope> ou pelo valor <Prefix>. Por exemplo, o seguinte resulta numa chave da cache de UserToken__apiAccessToken__<value_of_client_id>:

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

Usa o elemento <CacheKey> em conjunto com <Prefix> e <Scope>. Para mais informações, consulte o artigo Trabalhar com chaves de cache.

Elemento <CacheLookupTimeoutInSeconds>

Especifica o número de segundos após o qual uma pesquisa de cache sem êxito é considerada uma cache em falta. Se isto ocorrer, o fluxo é retomado ao longo do caminho da cache em falta.

<CacheLookupTimeoutInSeconds>30</CacheLookupTimeoutInSeconds>

Predefinição:	30
Presença:	Opcional
Tipo:	Número inteiro

Elemento <CacheResource>

Especifica a cache onde as mensagens devem ser armazenadas. Omita este elemento para usar a cache partilhada incluída. Deve especificar um CacheResource pelo nome se quiser poder limpar administrativamente as entradas contidas na cache. Para mais informações, consulte a API Caches.

<CacheResource>cache_to_use</CacheResource>

Predefinição:	N/A
Presença:	Opcional
Tipo:	String

Elemento <CacheKey>/<KeyFragment>

Especifica um valor que deve ser incluído na chave da cache, criando um espaço de nomes para a correspondência de pedidos com respostas em cache.

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

Predefinição:	N/A
Presença:	Opcional
Tipo:	N/A

Pode ser uma chave (um nome estático que fornece) ou um valor (uma entrada dinâmica definida através da referência a uma variável). Todos os fragmentos especificados combinados (mais o prefixo) são concatenados para criar a chave da cache.

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

Usa o elemento <KeyFragment> em conjunto com <Prefix> e <Scope>. Para mais informações, consulte o artigo Trabalhar com chaves de cache.

Atributos

Atributo	Tipo	Predefinição	Obrigatória	Descrição
ref	de string		Não	A variável a partir da qual obter o valor. Não deve ser usado se este elemento contiver um valor literal.

Elemento <CacheKey>/<Prefix>

Especifica um valor a usar como prefixo da chave de cache.

<Prefix>prefix_string</Prefix>

Predefinição:	N/A
Presença:	Opcional
Tipo:	String

Use este valor em vez de <Scope> quando quiser especificar o seu próprio valor em vez de um valor enumerado <Scope>. Se estiver definido, <Prefix> antepõe o valor da chave da cache às entradas escritas na cache. Um valor do elemento <Prefix> substitui um valor do elemento <Scope>.

Usa o elemento <Prefix> em conjunto com <CacheKey> e <Scope>. Para mais informações, consulte o artigo Trabalhar com chaves de cache.

Elemento <ExcludeErrorResponse>

Esta política pode colocar em cache respostas HTTP com qualquer código de estado. Isto significa que as respostas de êxito e de erro podem ser colocadas em cache, incluindo códigos de estado 2xx e 3xx.

Defina este elemento como true (predefinição) para excluir as respostas de erro. Defina-o como false se não quiser excluir respostas de destino da cache com códigos de estado de erro HTTP.

Nota: os códigos de estado de 200 a 205 continuam a ser colocados em cache quando este elemento está definido como true. Estes são os códigos de estado HTTP que o Apigee considera códigos de "êxito" e não os pode excluir com este elemento.

Para uma discussão sobre padrões de cache de respostas em que este elemento é útil, consulte o artigo Introdução aos antipadrões.

<ExcludeErrorResponse>true</ExcludeErrorResponse>

Predefinição:	verdadeiro
Presença:	Opcional
Tipo:	Booleano

Elemento <ExpirySettings>

Especifica quando uma entrada de cache deve expirar. Quando presente, <TimeoutInSeconds> substitui <TimeOfDay> e <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>

Predefinição:	N/A
Presença:	Obrigatória
Tipo:	N/A

Elemento <ExpirySettings>/<ExpiryDate>

Especifica a data em que uma entrada da cache deve expirar. Use o formulário mm-dd-yyyy. Quando presente, o elemento irmão deste elemento, <TimeoutInSeconds>, substitui <ExpiryDate>.

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

Predefinição:	N/A
Presença:	Opcional
Tipo:	String

Atributos

<ExpiryDate ref="" />

Atributo	Descrição	Predefinição	Presença	Tipo
ref	A variável a partir da qual obter o valor. Não deve ser usado se este elemento contiver um valor literal.	N/A	Opcional	String

Elemento <ExpirySettings>/<TimeOfDay>

A hora do dia em que uma entrada da cache deve expirar. Use o formulário hh:mm:ss . Quando presente, o elemento irmão deste elemento, <TimeoutInSeconds>, substitui <TimeOfDay>.

Introduza a hora do dia no formato HH:mm:ss, em que HH representa a hora num relógio de 24 horas. Por exemplo, 14:30:00 para 14:30.

Para a hora do dia, o local e o fuso horário predefinidos variam consoante o local onde o código está a ser executado (que não é conhecido quando configura a política).

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

Predefinição:	N/A
Presença:	Opcional
Tipo:	String

Atributos

Atributo	Descrição	Predefinição	Presença	Tipo
ref	Variável com o valor da hora de validade.	N/A	Opcional	String

Elemento <ExpirySettings>/<TimeoutInSec>

Nota: descontinuado. Use TimeoutInSeconds. Se os elementos TimeoutInSec e TimeoutInSeconds estiverem presentes, o Apigee usa TimeoutInSeconds.

O número de segundos após os quais uma entrada de cache deve expirar.

Elemento <ExpirySettings>/<TimeoutInSeconds>

O número de segundos após os quais uma entrada de cache deve expirar. Quando presente, este elemento substitui os respetivos elementos irmãos, <TimeOfDay> e <ExpiryDate>.

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

Nota: indique um valor de tempo limite predefinido a usar se a ref não receber um valor do duration_variable.

Predefinição:	N/A
Presença:	Opcional
Tipo:	String

Atributos

Atributo	Descrição	Predefinição	Presença	Tipo
ref	Variável com o valor de limite de tempo.	N/A	Opcional	String

Elemento <Scope>

Enumeração usada para construir um prefixo para uma chave de cache quando um elemento <Prefix> não é fornecido no elemento <CacheKey>.

<Scope>scope_enumeration</Scope>

Predefinição:	"Exclusivo"
Presença:	Opcional
Tipo:	String

A definição <Scope> determina uma chave de cache que é adicionada de acordo com o valor <Scope>. Por exemplo, uma chave de cache teria o seguinte formato quando o âmbito é definido como Exclusive: orgName__envName__apiProxyName__proxy|TargetName__ [ serializedCacheKey ].

Se um elemento <Prefix> estiver presente em <CacheKey>, substitui o valor do elemento <Scope>. Os valores válidos incluem as enumerações abaixo.

Usa o elemento <Scope> em conjunto com <CacheKey> e <Prefix>. Para mais informações, consulte o artigo Trabalhar com chaves de cache.

Valores aceitáveis

Valor do âmbito	Descrição
Global	A chave da cache é partilhada por todos os proxies de API implementados no ambiente. A chave da cache é adicionada no início no formato orgName __ envName __. Se definir uma entrada <CacheKey> com o <KeyFragment> apiAccessToken e um âmbito <Global>, cada entrada é armazenada como orgName__envName__apiAccessToken, seguida do valor serializado do token de acesso. Para um proxy de API implementado num ambiente denominado "test" numa organização denominada "apifactory", os tokens de acesso seriam armazenados na seguinte chave de cache: apifactory__test__apiAccessToken.
Application	O nome do proxy da API é usado como prefixo. A chave da cache é adicionada no formulário orgName__envName__apiProxyName.
Proxy	A configuração ProxyEndpoint é usada como prefixo. A chave da cache é adicionada sob a forma orgName__envName__apiProxyName__proxyEndpointName .
Target	A configuração TargetEndpoint é usada como prefixo. Chave de cache anteposta no formulário orgName__envName__apiProxyName__targetEndpointName .
Exclusive	Predefinição. Esta é a mais específica e, por isso, apresenta um risco mínimo de colisões de espaço de nomes numa determinada cache. O prefixo tem um de dois formatos: Se a política estiver anexada ao fluxo ProxyEndpoint, o prefixo tem o formato ApiProxyName_ProxyEndpointName. Se a política estiver anexada em TargetEndpoint, o prefixo tem o formato ApiProxyName_TargetName. Chave da cache anteposta no formulário orgName__envName__apiProxyName__proxyNameITargetName Por exemplo, a string completa pode ter o seguinte aspeto: apifactory__test__weatherapi__default__apiAccessToken .

Elemento <SkipCacheLookup>

Define uma expressão que, se for avaliada como verdadeira no tempo de execução, especifica que a pesquisa na cache deve ser ignorada e a cache deve ser atualizada. Veja também o vídeo Usar a política ResponseCache sobre a utilização da SkipCacheLookup.

<SkipCacheLookup>variable_condition_expression</SkipCacheLookup>

Predefinição:	N/A
Presença:	Opcional
Tipo:	String

No exemplo seguinte, se a variável bypass-cache estiver definida como true num cabeçalho recebido, a procura na cache é ignorada e a cache é atualizada.

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

Elemento <SkipCachePopulation>

Define uma expressão que, se for avaliada como verdadeira no tempo de execução, especifica que uma gravação na cache deve ser ignorada. Veja também este vídeo sobre a utilização do SkipCachePopulation.

<SkipCachePopulation>variable_condition_expression</SkipCachePopulation>

Predefinição:	N/A
Presença:	Opcional
Tipo:	String

Por exemplo, o seguinte ignoraria a gravação na cache se o código de estado da resposta fosse 400 ou superior:

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

Elemento <UseAcceptHeader>

Defina como true para que a chave de cache de uma entrada de cache de resposta seja anexada com valores dos cabeçalhos Accept de resposta.

O Apigee usa os cabeçalhos de pedido Accept, Accept-Encoding, Accept-Language e Accept-Charset quando calcula a chave da cache. Esta abordagem impede que um cliente receba um tipo de suporte que não pediu.

Por exemplo, considere se chegarem duas solicitações do mesmo URL, em que a primeira solicitação aceita gzip e a segunda não. O primeiro pedido é colocado em cache e a entrada em cache é (provavelmente) uma resposta comprimida com gzip. O segundo pedido lê o valor em cache e, em seguida, pode devolver uma entrada comprimida com gzip a um cliente que não consiga ler gzip.

Consulte o artigo Configurar uma chave de cache para mais informações.

<UseAcceptHeader>false</UseAcceptHeader>

Predefinição:	falso
Presença:	Opcional
Tipo:	Booleano

Elemento <UseResponseCacheHeaders>

Defina como true para que os cabeçalhos de resposta HTTP sejam considerados ao definir o "tempo de vida" (TTL) da resposta na cache. Quando esta opção é verdadeira, o Apigee considera os valores dos seguintes cabeçalhos de resposta, comparando-os com os valores definidos por <ExpirySettings> ao definir o tempo de vida:

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

Consulte o artigo Definir a expiração da entrada na cache para mais detalhes.

<UseResponseCacheHeaders>false</UseResponseCacheHeaders>

Predefinição:	falso
Presença:	Opcional
Tipo:	Booleano

Notas de utilização

O tamanho máximo de cada objeto em cache é de 256 KB. (Para informações detalhadas sobre como o Apigee processa a cache, consulte o artigo Funcionamento interno da cache.)

Através da configuração na política ResponseCache, pode fazer com que o Apigee inclua cabeçalhos de resposta HTTP na definição da expiração da entrada de cache e das chaves de cache. Esta secção descreve como pode usar a política de cache com cabeçalhos para gerir a expiração da cache e as chaves de cache.

Para saber mais sobre como o Apigee processa os cabeçalhos de resposta com a política ResponseCache, consulte o artigo Suporte para cabeçalhos de resposta HTTP.

Nota: para outras sugestões de práticas recomendadas relacionadas com a política ResponseCache, consulte o artigo Práticas recomendadas para a conceção e o desenvolvimento de proxies de API.

Definir a validade da entrada de cache

Tal como na política PopulateCache, pode definir a expiração de uma entrada da cache de respostas (o respetivo tempo de vida) através do elemento <ExpirySettings>. Na política ResponseCache, também pode fazer com que o Apigee considere os cabeçalhos de resposta quando estiverem presentes.

Para usar cabeçalhos de resposta, defina o valor do elemento <UseResponseCacheHeaders> como verdadeiro. Essa definição faz com que o Apigee considere os cabeçalhos de resposta, compare-os com o valor definido por <ExpirySettings> e, em seguida, use o valor mais baixo entre os dois. Ao considerar os cabeçalhos de resposta, o Apigee escolhe o valor disponível, conforme descrito no seguinte:

Por exemplo, imagine que uma resposta é colocada em cache com os seguintes valores:

• Nenhum valor Cache-Control s-maxage
• Um valor Cache-Control max-age de 300
• Uma data Expires dentro de três dias
• Um valor <ExpirySettings> TimeoutInSeconds de 600.

Neste caso, o valor Cache-Control max-age seria usado para o TTL porque é inferior ao valor <ExpirySettings> e porque não existe um valor Cache-Control s-maxage (que tem precedência sobre max-age).

Configurar uma chave de cache

Tal como acontece com as políticas de cache de fins gerais, como a política PopulateCache, com a ResponseCache, usa os elementos <CacheKey> e <Scope> para configurar a criação de chaves de cache para entradas de cache. Com o ResponseCache, também pode tornar as chaves da cache mais significativas ao anexar os cabeçalhos Accept das respostas aos valores das chaves.

Para obter informações gerais sobre a configuração de chaves de cache, consulte o artigo Trabalhar com chaves de cache. Para ver informações sobre a utilização de cabeçalhos Accept, consulte <UseAcceptHeader>.

Acerca da encriptação da cache

Apigee e Apigee híbrido (versão 1.4 e posteriores): os dados da cache e do KVM são sempre encriptados.

Variáveis de fluxo

As seguintes variáveis de fluxo predefinidas são preenchidas quando uma política ResponseCache é executada. Para mais informações sobre as variáveis de fluxo, consulte a referência de variáveis de fluxo.

Variáveis	Tipo	Autorização	Descrição
responsecache.{policy_name}.cachename	String	Só de leitura	Devolve a cache usada na política
responsecache.{policy_name}.cachekey	String	Só de leitura	Devolve a chave usada
responsecache.{policy_name}.cachehit	Booleano	Só de leitura	Verdadeiro se a execução da política for bem-sucedida
responsecache.{policy_name}.invalidentry	Booleano	Só de leitura	Verdadeiro se a entrada da cache não for válida

Códigos de erro

Esta secção descreve as mensagens de erro e as variáveis de fluxo que são definidas quando esta política aciona um erro. Estas informações são importantes se estiver a desenvolver regras de falhas para um proxy. Para saber mais, consulte o artigo O que precisa de saber acerca dos erros de políticas e Como processar falhas.

Prefixo do código de erro

N/A

Erros de tempo de execução

Esta política não gera erros de tempo de execução.

Erros de implementação

Estes erros podem ocorrer quando implementa um proxy que contém esta política.

Sugestão: precisa de ajuda para resolver um erro? Clique em na coluna Corrigir para ver informações detalhadas de resolução de problemas.

Nome do erro	Causa	Corrigir
InvalidTimeout	Se o elemento <CacheLookupTimeoutInSeconds> da política ResponseCache estiver definido como um número negativo, a implementação do proxy de API falha.
InvalidCacheResourceReference	Este erro ocorre se o elemento <CacheResource> numa política ResponseCache estiver definido para um nome que não existe no ambiente onde o proxy de API está a ser implementado.
ResponseCacheStepAttachmentNotAllowedReq	Este erro ocorre se a mesma política ResponseCache estiver anexada a vários caminhos de pedidos em quaisquer fluxos de um proxy de API.
ResponseCacheStepAttachmentNotAllowedResp	Este erro ocorre se a mesma política ResponseCache estiver anexada a vários caminhos de resposta em quaisquer fluxos de um proxy de API.
InvalidMessagePatternForErrorCode	Este erro ocorre se o elemento <SkipCacheLookup> ou <SkipCachePopulation> numa política ResponseCache contiver uma condição inválida.
CacheNotFound	Este erro ocorre se a cache específica mencionada na mensagem de erro não tiver sido criada num componente do processador de mensagens específico.

Variáveis de falha

N/A

Exemplo de resposta de erro

N/A

Esquema

Cada tipo de política é definido por um esquema XML (.xsd). Para referência, os esquemas de políticas estão disponíveis no GitHub.