Partage via

Forward request

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.

Note

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.

Policy statement

<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"/>

Attributes

Attribute Description Required Default
timeout 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. No 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. No 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. No N/A
http-version Version du protocole HTTP à utiliser lors de l’envoi de la requête HTTP au service principal :
- 1: HTTP/1
- 2: HTTP/2
- 2or1: la passerelle privilégie HTTP/2 sur HTTP/1, mais revient à HTTP/1 si HTTP/2 ne fonctionne pas.

Le trafic sortant HTTP/2 est pris en charge dans les passerelles sélectionnées. Pour plus d’informations, consultez les notes d’utilisation .		 No 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. No 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. No 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.		 No 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. No false

Usage

Usage notes

  • Utilisez l’attribut http-version pour activer le protocole HTTP/2 sortant de la passerelle vers le serveur principal. Définissez l’attribut sur 2or1 ou 2. Actuellement, le trafic sortant HTTP/2 est pris en charge dans la passerelle auto-hébergée et en préversion dans la passerelle v2.

    Important

    Dans la passerelle v2, HTTP/2 est pris en charge entrant vers la passerelle Gestion des API et sortant de la passerelle vers le serveur principal, mais pas de bout en bout. Actuellement, la passerelle v2 rétrograde une connexion HTTP/2 entrante vers HTTP/1 avant de transférer la requête vers le back-end.

Examples

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. Par exemple, utilisez cette stratégie pour transférer des demandes d’une passerelle auto-hébergée vers un serveur principal gRPC.

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

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>

Related content

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

  • Last updated on