Partager via

Transférer la requête

  • Article

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

La stratégie forward-request transfère la demande entrante au service principal spécifié dans le forward-request de la demande. L’URL du service back-end est spécifiée dans les paramètres de l’API et peut être modifiée à l’aide de la stratégie set backend service.

Important

  • Cette stratégie est nécessaire pour transférer des requêtes vers un back-end d’API. Par défaut, le service Gestion des API configure cette stratégie à l’étendue globale.
  • La suppression de cette stratégie empêche le transfert de la requête vers le service back-end. Les stratégies de la section sortante sont évaluées immédiatement après la réussite des stratégies dans la section entrante.

Notes

Définissez les éléments enfants et de stratégie dans l’ordre fourni dans l’instruction de stratégie. En savoir plus sur comment définir ou modifier des stratégies du service Gestion des API.

Instruction de la stratégie

<forward-request http-version="1 | 2or1 | 2" timeout="time in seconds (alternatively, use timeout-ms)" | timeout-ms="time in milliseconds (alternatively, use timeout)" continue-timeout="time in seconds" follow-redirects="false | true" buffer-request-body="false | true" buffer-response="true | false" fail-on-error-status-code="false | true"/>

Attributs

Attribut Description Obligatoire Default
délai d'expiration Durée, en secondes, de l’attente du retour des en-têtes de réponse HTTP par le service back-end avant de déclencher une erreur de délai d’expiration. La valeur minimale est 0 seconde. Il est possible que les valeurs supérieures à 240 secondes ne soient pas prises en compte, car l’infrastructure réseau sous-jacente peut supprimer des connexions inactives après ce délai. Les expressions de stratégie sont autorisées. Vous pouvez spécifier timeout ou timeout-ms, mais pas les deux. Non 300
timeout-ms Durée, en millisecondes, de l’attente du retour des en-têtes de réponse HTTP par le service back-end avant de déclencher une erreur de délai d’expiration. La valeur minimale est 0 ms. Les expressions de stratégie sont autorisées. Vous pouvez spécifier timeout ou timeout-ms, mais pas les deux. Non N/A
continue-timeout La durée, en secondes, de l’attente du retour pour un 100 Continuecode d’état par le service back-end avant de déclencher une erreur de délai d’expiration. Les expressions de stratégie sont autorisées. Non N/A
http-version Version de la spécification HTTP à utiliser lors de l’envoi de la réponse HTTP au service back-end. Lorsque vous utilisez 2or1, la passerelle privilégie HTTP/2 par rapport à /1, mais revient à HTTP/1 si HTTP/2 ne fonctionne pas. Non 1
follow-redirects Indique si les redirections à partir du service principal sont suivies par la passerelle ou renvoyées à l’appelant. Les expressions de stratégie sont autorisées. Non false
buffer-request-body Quand la valeur est définie sur true, la demande est mise en mémoire tampon et est réutilisée lors d’une nouvelle tentative. Non false
buffer-response Affecte le traitement des réponses mémorisées en bloc. Quand la valeur est définie sur false, chaque bloc reçu du back-end est retourné immédiatement à l’appelant. Quand la valeur est définie sur true, les blocs sont mis en mémoire tampon (8 Ko, sauf si la fin du flux est détectée) puis retournés à l’appelant.

Définissez la valeur sur false avec les back-ends comme ceux qui implémentent des événements envoyés par le serveur (SSE) nécessitant que le contenu soit retourné ou transmis en continu immédiatement à l’appelant. Les expressions de stratégie ne sont pas autorisées.		 Non true
fail-on-error-status-code Quand la valeur est définie sur true, la section on-error est déclenchée pour les codes de réponse dans la plage comprise entre 400 et 599. Les expressions de stratégie ne sont pas autorisées. Non false

Usage

Exemples

Envoyer une requête au service back-end HTTP/2

La stratégie au niveau de l’API suivante transfère toutes les requêtes d’API à un service back-end HTTP/2.

<!-- api level -->
<policies>
    <inbound>
        <base/>
    </inbound>
    <backend>
        <forward-request http-version="2or1"/>
    </backend>
    <outbound>
        <base/>
    </outbound>
</policies>

Cela est requis pour les charges de travail HTTP/2 ou gRPC et actuellement pris en charge uniquement dans la passerelle auto-hébergée. Découvrez-en plus dans notre présentation de la passerelle API.

Transférer la demande avec intervalle de délai d’expiration

La stratégie au niveau de l’API suivante transfère toutes les demandes d’API au service back-end avec un délai d’expiration de 60 secondes.

<!-- api level -->
<policies>
    <inbound>
        <base/>
    </inbound>
    <backend>
        <forward-request timeout="60"/>
    </backend>
    <outbound>
        <base/>
    </outbound>
</policies>

Hériter la stratégie de l’étendue parente

Cette stratégie au niveau de l’opération utilise l’élément base pour hériter de la stratégie backend de l’étendue au niveau de l’API parente.

<!-- operation level -->
<policies>
    <inbound>
        <base/>
    </inbound>
    <backend>
        <base/>
    </backend>
    <outbound>
        <base/>
    </outbound>
</policies>

Ne pas hériter la stratégie de l’étendue parente

Cette stratégie au niveau de l’opération transfère explicitement toutes les demandes au service principal avec un délai d’expiration de 120 secondes et n’hérite pas de la stratégie principale au niveau de l’API parente. Si le service back-end répond avec un code d’état d’erreur compris entre 400 et 599, la section on-error sera déclenchée.

<!-- operation level -->
<policies>
    <inbound>
        <base/>
    </inbound>
    <backend>
        <forward-request timeout="120" fail-on-error-status-code="true" />
        <!-- effective policy. note the absence of <base/> -->
    </backend>
    <outbound>
        <base/>
    </outbound>
</policies>

Ne pas transférer les demandes au back-end

Cette stratégie au niveau de l’opération ne transmet pas de requêtes au service principal.

<!-- operation level -->
<policies>
    <inbound>
        <base/>
    </inbound>
    <backend>
        <!-- no forwarding to backend -->
    </backend>
    <outbound>
        <base/>
    </outbound>
</policies>

Contenu connexe

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