Configurar uma política de cache
A maioria das organizações precisa de um desempenho de API excelente. Ao usar um cache de respostas compiladas no Gerenciamento de API do Azure, é possível reduzir o tempo que uma API leva para responder a chamadas.
Imagine que há uma necessidade de que a API de jogos de tabuleiro dê respostas mais rápidas às solicitações. Por exemplo, geralmente, os usuários solicitam os preços de vários tamanhos de tabuleiros de jogos. As políticas do Gerenciamento de API podem acelerar as respostas configurando um cache de respostas preparadas. Quando uma solicitação de um usuário é recebida, o Gerenciamento de API a verifica para saber se já há uma resposta apropriada no cache. Se houver, essa resposta poderá ser enviada ao usuário sem precisar criá-la novamente na fonte de dados.
Aqui, você aprenderá a configurar esse cache.
Como controlar o cache do Gerenciamento de API
Para configurar um cache, use uma política de saída chamada cache-store para armazenar respostas. Use também uma política de entrada chamada cache-lookup para verificar se há uma resposta em cache para a solicitação atual. É possível ver essas duas políticas no exemplo abaixo:
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store duration="60" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Também é possível armazenar valores individuais no cache em vez de uma resposta completa. Use a política cache-store-value para adicionar o valor com uma chave de identificação. Recupere o valor do cache usando a política cache-lookup-value. Se você quiser remover um valor antes que ele expire, use a política cache-remove-value:
<policies>
<inbound>
<cache-lookup-value key="12345"
default-value="$0.00"
variable-name="boardPrice"
caching-type="internal" />
<base />
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store-value key="12345"
value="$3.60"
duration="3600"
caching-type="internal" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Usar tags vary-by
É importante garantir que, se você atender a uma resposta do cache, ela seja relevante para a solicitação original. No entanto, também é conveniente usar o cache o máximo possível. Por exemplo, imagine que a API de Gerenciamento de Estoque de jogos de tabuleiro recebeu uma solicitação GET para a seguinte URL e armazenou o resultado em cache:
http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=1128
Essa solicitação deve verificar os níveis de estoque de um produto com o número de peça 3416. A ID do cliente é usada por outra política e não altera a resposta. As solicitações posteriores do mesmo número de peça podem ser enviadas do cache, desde que o registro não tenha expirado. Até agora, tudo bem.
Agora, imagine que um cliente diferente solicitou o mesmo produto:
http://<boardgames.domain>/stock/api/product?partnumber=3416&customerid=5238
Por padrão, a resposta não pode ser enviada do cache, porque a ID do cliente é diferente.
No entanto, os desenvolvedores ressaltam que a ID do cliente não altera a resposta. Seria mais eficiente se as solicitações de clientes diferentes para o mesmo produto pudessem ser retornadas do cache. Os clientes ainda veriam as informações corretas.
Para modificar esse comportamento padrão, use o elemento vary-by-query-parameter na política <cache-lookup>:
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" must-revalidate="true" caching-type="internal">
<vary-by-query-parameter>partnumber</vary-by-query-parameter>
</cache-lookup>
</inbound>
<backend>
<base />
</backend>
<outbound>
<cache-store duration="60" />
<base />
</outbound>
</on-error>
<base />
</on-error>
</policies>
Com essa política, o cache armazena e separa as respostas para cada produto porque eles têm diferentes números de partes. O cache não armazenará respostas diferentes para cada cliente, porque esse parâmetro de consulta não está listado.
Por padrão, o Gerenciamento de API do Azure não examina cabeçalhos HTTP para determinar se uma resposta armazenada em cache é adequada para alguma solicitação. Se um cabeçalho fizer uma diferença significativa para uma resposta, use a tag <vary-by-header>. Trabalhe com sua equipe de desenvolvedores para entender como cada API usa os parâmetros de consulta e os cabeçalhos para decidir qual tag vary-by usar em sua política.
Na tag <cache-lookup>, também há o atributo vary-by-developer, que é obrigatório e definido como false por padrão. Quando esse atributo está definido como true, o Gerenciamento de API examina a chave de assinatura fornecida com cada solicitação. Ele só atenderá a uma resposta do cache se a solicitação original tiver a mesma chave de assinatura. Defina este atributo como true para que cada usuário veja uma resposta diferente para o mesmo URL. Para que cada grupo de usuários veja uma resposta diferente da mesma URL, defina o atributo vary-by-developer-group como true.
Usar um cache externo
Geralmente, as instâncias do Gerenciamento de API têm um cache interno usado para armazenar as respostas preparadas. No entanto, se você preferir, será possível usar um cache externo compatível com Redis como alternativa. Um sistema de cache externo que você pode usar é o serviço Cache do Azure para Redis.
Você pode optar por usar um cache externo porque:
- Quer evitar que o cache seja apagado quando o serviço de Gerenciamento de API for atualizado.
- Deseja ter mais controle sobre a configuração do cache que o permitido pelo cache interno.
- Você quer armazenar mais dados em cache que o limite do cache interno.
Outro motivo para configurar um cache externo é usar o armazenamento em cache com o tipo de preço de Consumo. Essa camada segue a entidade de segurança de design sem servidor e você deve usá-la com APIs Web sem servidor. Por esse motivo, ela não tem cache interno. Se você quiser usar o cache com uma instância do Gerenciamento de API na camada Consumo, use um cache externo.