Condividi tramite

Forward request

SI APPLICA A: Tutti i livelli di Gestione API

Il criterio forward-request inoltra la richiesta in ingresso al servizio back-end specificato nel contesto della richiesta. L'URL del servizio back-end è specificato nelle impostazioni API e può essere modificato tramite il criterio imposta servizio back-end.

Important

  • Questo criterio è necessario per inoltrare le richieste a un back-end dell'API. Per impostazione predefinita, Gestione API configura questi criteri con ambito globale.
  • Se si rimuovono questi criteri, la richiesta non verrà inoltrata al servizio back-end. I criteri della sezione outbound vengono valutati subito dopo il completamento dei criteri della sezione inbound.

Note

Impostare gli elementi e gli elementi figlio del criterio nell'ordine specificato nell'istruzione del criterio. Altre informazioni su come impostare o modificare i criteri di API Management.

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 Quantità di tempo di attesa in secondi affinché le intestazioni di risposta HTTP vengano restituite dal servizio di back-end prima che venga generato un errore di timeout. Il valore minimo è 0 secondi. I valori maggiori di 240 secondi potrebbero non essere rispettati, perché l'infrastruttura di rete sottostante può rimuovere le connessioni inattive dopo questo tempo. Le espressioni di criteri sono consentite. È possibile specificare timeout oppure timeout-ms, non entrambi. No 300
timeout-ms Quantità di tempo di attesa in millisecondi affinché le intestazioni di risposta HTTP vengano restituite dal servizio di back-end prima che venga generato un errore di timeout. Il valore minimo è 0 ms. Le espressioni di criteri sono consentite. È possibile specificare timeout oppure timeout-ms, non entrambi. No N/A
continue-timeout Quantità di tempo di attesa in secondi affinché il codice di stato 100 Continue venga restituito dal servizio di back-end prima che venga generato un errore di timeout. Le espressioni di criteri sono consentite. No N/A
http-version Versione del protocollo HTTP da usare quando si invia la richiesta HTTP al servizio back-end:
- 1: HTTP/1
- 2: HTTP/2
- 2or1: il gateway favorisce HTTP/2 su HTTP/1, ma esegue il fallback a HTTP/1 se HTTP/2 non funziona.

HTTP/2 in uscita è supportato nei gateway selezionati. Per informazioni dettagliate, vedere Note sull'utilizzo .		 No 1
follow-redirects Specifica se i reindirizzamenti dal servizio back-end sono seguiti dal gateway o restituiti al chiamante. Le espressioni di criteri sono consentite. No false
buffer-request-body Se impostato su true, la richiesta viene memorizzata nel buffer e verrà riutilizzata al successivo retry. No false
buffer-response Influisce sull'elaborazione delle risposte in blocchi. Se impostato su false, ogni blocco ricevuto dal back-end viene immediatamente restituito al chiamante. Se impostata su true, i blocchi vengono memorizzati nel buffer (8 KB, a meno che non venga rilevata la fine del flusso) e restituiti solo al chiamante.

Impostare su false con back-end, ad esempio quelli che implementano eventi inviati dal server (SSE) che richiedono che il contenuto venga restituito o trasmesso immediatamente al chiamante. Le espressioni di criteri non sono consentite.		 No true
fail-on-error-status-code Se impostato su true, attiva la sezione on-error per i codici di risposta compresi tra 400 e 599 inclusi. Le espressioni di criteri non sono consentite. No false

Usage

Usage notes

  • Usare l'attributo http-version per abilitare il protocollo HTTP/2 in uscita dal gateway al back-end. Impostare l'attributo su 2or1 o 2. Attualmente, HTTP/2 in uscita è supportato nel gateway self-hosted e in anteprima nel gateway v2.

    Important

    Nel gateway v2 HTTP/2 è supportato in ingresso al gateway di Gestione API e in uscita dal gateway al back-end, ma non end-to-end. Attualmente, il gateway v2 effettua il downgrade di una connessione HTTP/2 in ingresso a HTTP/1 prima di inoltrare la richiesta al back-end.

Examples

Inviare una richiesta al back-end HTTP/2

I seguenti criteri a livello di API inoltrano tutte le richieste API a un servizio back-end HTTP/2. Ad esempio, usare questo criterio per inoltrare le richieste da un gateway self-hosted a un back-end gRPC.

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

Inoltrare la richiesta con un intervallo di timeout

Il criterio a livello di API seguente inoltra tutte le richieste API al servizio back-end con un intervallo di timeout di 60 secondi.

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

Ereditare i criteri dall'ambito padre

Questo criterio a livello di operazione usa l'elemento base per ereditare il criterio di back-end dall'ambito di livello API padre.

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

Non ereditare i criteri dall'ambito padre

Questo criterio a livello di operazione inoltra in modo esplicito tutte le richieste al servizio back-end con un timeout di 120 e non eredita il criterio di back-end a livello API padre. Se il servizio back-end risponde con un codice di stato di errore compreso tra 400 e 599 inclusi, verrà attivata la sezione on-error.

<!-- 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>

Non inoltrare richieste al back-end

Questo criterio a livello di operazione non inoltra le richieste al servizio back-end.

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

Related content

Per ulteriori informazioni sull'utilizzo dei criteri, vedere:

  • Last updated on