Inoltro richiesta

  • Articolo

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.

Importante

  • 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.

Nota

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.

Istruzione del criterio

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

Attributi

Attributo Descrizione Richiesto Valore predefinito
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/D
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/D
http-version Versione HTTP specifica da usare quando si invia la risposta HTTP al servizio di back-end. Quando si usa 2or1, il gateway privilegia HTTP /2 rispetto a /1, ma esegue il fallback a HTTP /1 se HTTP /2 non funziona. 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

Utilizzo

Esempi

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.

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

Questa operazione è necessaria per i carichi di lavoro HTTP/2 o gRPC ed è attualmente supportata solo nel gateway self-hosted. Per altre informazioni, vedere la panoramica sul gateway API.

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>

Contenuto correlato

Per ulteriori informazioni sull'utilizzo dei criteri, vedere: