Partager via

Obtention à partir du cache

S’APPLIQUE À : tous les niveaux de Gestion des API

Utilisez la stratégie cache-lookup pour effectuer une recherche dans le cache et renvoyer une réponse mise en cache valide si elle est disponible. Cette stratégie peut être appliquée dans les cas où le contenu de la réponse reste statique pendant un certain temps. La mise en cache de la réponse réduit les besoins en bande passante et en calcul imposés par le serveur web principal et limite la latence perçue par les consommateurs de l’API.

Notes

Cette stratégie doit avoir une stratégie Store to cache correspondante.

Important

Le cache intégré est volatile et partagé par toutes les unités de la même région dans le même service de gestion des API.

Notes

Définissez les éléments enfants et de stratégie dans l’ordre fourni dans l’instruction de stratégie. Pour vous aider à configurer cette stratégie, le portail fournit un éditeur guidé basé sur des formulaires. En savoir plus sur comment définir ou modifier des stratégies du service Gestion des API.

Instruction de la stratégie

<cache-lookup vary-by-developer="true | false" vary-by-developer-groups="true | false" caching-type="prefer-external | external | internal" downstream-caching-type="none | private | public" must-revalidate="true | false" allow-private-response-caching="@(expression to evaluate)">
  <vary-by-header>Accept</vary-by-header>
  <!-- should be present in most cases -->
  <vary-by-header>Accept-Charset</vary-by-header>
  <!-- should be present in most cases -->
  <vary-by-header>Authorization</vary-by-header>
  <!-- should be present when allow-private-response-caching is "true"-->
  <vary-by-header>header name</vary-by-header>
  <!-- optional, can be repeated -->
  <vary-by-query-parameter>parameter name</vary-by-query-parameter>
  <!-- optional, can be repeated -->
</cache-lookup>

Attributs

Attribut Descriptif Obligatoire Par défaut
allow-private-response-caching Lorsque l’attribut est défini sur true, permet la mise en cache des requêtes qui contiennent un en-tête d’autorisation. Les expressions de stratégie sont autorisées. Non false
mise en cache-type Choisissez entre les valeurs suivantes de l’attribut :
- internal pour utiliser le cache Gestion des API intégré,
- external pour utiliser le cache externe (voir - ,
- prefer-external pour utiliser un cache externe (si configuré) ou un cache interne sinon.

Les expressions de stratégie ne sont pas autorisées.		 Non prefer-external
type de mise en cache en aval Cet attribut doit avoir l’une des valeurs suivantes.

- none : la mise en cache en aval n’est pas autorisée.
- private : la mise en cache privée en aval est autorisée.
- public : la mise en cache privée et partagée en aval est autorisée.

Les expressions de stratégie sont autorisées.		 Non Aucun
doit-vérifier-validité Lorsque la mise en cache en aval est activée, cet attribut active ou désactive la directive de contrôle de cache must-revalidate dans les réponses de la passerelle. Les expressions de stratégie sont autorisées. Non true
vary-by-developer Définissez la valeur true pour mettre en cache les réponses par compte de développeur possédant une true incluse dans la demande. Les expressions de stratégie sont autorisées. Oui false
vary-by-developer-groups Attribut défini sur true pour mettre en cache des réponses par true. Les expressions de stratégie sont autorisées. Oui false

Éléments

Nom Descriptif Obligatoire
vary-by-header Ajoutez un ou plusieurs de ces éléments pour commencer à mettre en cache les réponses par valeur d’en-tête spécifié, par exemple, Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Expect, From, Host ou If-Match. Non
vary-by-query-parameter Ajoutez un ou plusieurs de ces éléments pour commencer à mettre en cache les réponses par valeur de paramètre de requête spécifié. Entrez un ou plusieurs paramètres. Utilisez un point-virgule comme séparateur. Non

Utilisation

Notes d’utilisation

  • Gestion des API effectue uniquement une recherche de cache pour les requêtes HTTP GET.
  • Lorsque vous utilisez vary-by-query-parameter, vous pouvez déclarer les paramètres dans le modèle rewrite-uri ou affecter à l’attribut copy-unmatched-params la valeur false. En désactivant cet indicateur, les paramètres qui ne sont pas déclarés sont envoyés au back-end.
  • Cette stratégie ne peut être employée qu’une seule fois dans une section de stratégie.
  • Cette stratégie n’est pas prise en charge à l’intérieur d’un fragment de stratégie.
  • Nous vous recommandons de configurer une stratégie de limite de débit (ou une stratégie de limite de débit par clé ) immédiatement après toute recherche de cache. Cela permet à votre service principal d’être surchargé si le cache n’est pas disponible.

Exemples

Exemple avec la stratégie cache-store correspondante

Cet exemple montre comment utiliser la cache-store stratégie avec une cache-lookup stratégie pour mettre en cache les réponses dans le cache de gestion des API intégré.

Notes

Ajoutez une stratégie de limite de débit (ou une stratégie de limite de débit par clé ) après la recherche du cache pour limiter le nombre d’appels et empêcher la surcharge sur le service principal si le cache n’est pas disponible.

<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>version</vary-by-query-parameter>
        </cache-lookup>
        <rate-limit calls="10" renewal-period="60" />
    </inbound>
    <outbound>
        <cache-store duration="seconds" />
        <base />
    </outbound>
</policies>

Exemple utilisant des expressions de stratégie

Cet exemple montre comment configurer la durée de mise en cache des réponses de Gestion des API qui correspond à la mise en cache de la réponse du service principal, comme spécifié par la directive Cache-Control du service principal.

<!-- The following cache policy snippets demonstrate how to control API Management response cache duration with Cache-Control headers sent by the backend service. -->

<!-- Copy this snippet into the inbound section -->
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="public" must-revalidate="true" >
  <vary-by-header>Accept</vary-by-header>
  <vary-by-header>Accept-Charset</vary-by-header>
</cache-lookup>
 <rate-limit calls="10" renewal-period="60" />

<!-- Copy this snippet into the outbound section. Note that cache duration is set to the max-age value provided in the Cache-Control header received from the backend service or to the default value of 5 min if none is found  -->
<cache-store duration="@{
    var header = context.Response.Headers.GetValueOrDefault("Cache-Control","");        
    var maxAge = Regex.Match(header, "@(max-age=(?<maxAge>\\d+))").Groups["maxAge"]?.Value;
    return (!string.IsNullOrEmpty(maxAge))?int.Parse(maxAge):300; }" />

Pour plus d’informations, consultez les pages Expressions de stratégie et Variable de contexte.

Contenu connexe

Pour plus d’informations sur l’utilisation des stratégies, consultez :

  • Last updated on