Riferimento per la configurazione dei proxy API

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

In qualità di sviluppatore che lavora con Apigee, le tue attività di sviluppo principali riguardano la configurazione di proxy API che fungono da proxy per API o servizi di backend. Questo documento è un riferimento di tutti gli elementi di configurazione disponibili durante la creazione di proxy API.

Se stai imparando a creare proxy API, ti consigliamo di iniziare con l'argomento Creazione di un proxy API semplice.

Modifica la configurazione del proxy API utilizzando uno dei seguenti metodi:

Struttura delle directory di configurazione del proxy API

Di seguito è riportata la struttura della directory di configurazione del proxy API:

Mostra la struttura delle directory in cui apiproxy è la radice. Direttamente sotto la directory apiproxy si trovano le directory policies, proxies, resources e targets, nonché il file weatherapi.xml.

Una configurazione del proxy API è costituita dai seguenti contenuti:

Configurazione di base Impostazioni di configurazione principali per un proxy API.
ProxyEndpoint Impostazioni per la connessione HTTP in entrata (dalle app che richiedono ad Apigee), flussi di richieste e risposte e allegati delle norme.
TargetEndpoint Impostazioni per la connessione HTTP in uscita (da Apigee al servizio di backend), flussi di richieste e risposte e allegati dei criteri.
Flussi Pipeline di richiesta e risposta ProxyEndpoint e TargetEndpoint a cui possono essere collegati i criteri.
Norme File di configurazione in formato XML conformi agli schemi delle policy Apigee.
Risorse Script, file JAR e file XSLT a cui fanno riferimento le policy per eseguire una logica personalizzata.

Configurazione di base

/apiproxy/weatherapi.xml

La configurazione di base per un proxy API, che definisce il nome del proxy API. Il nome deve essere univoco all'interno di un'organizzazione.

Configurazione di esempio:

<APIProxy name="weatherapi">
</APIProxy>

Elementi di configurazione di base

Nome Descrizione Predefinito Obbligatorio?
APIProxy
name Il nome del proxy API, che deve essere univoco all'interno di un'organizzazione. I caratteri che puoi utilizzare nel nome sono limitati ai seguenti: A-Za-z0-9_- N/D Sì
revision Il numero di revisione della configurazione del proxy API. Non è necessario impostare esplicitamente il numero di revisione, poiché Apigee tiene traccia automaticamente della revisione corrente del proxy API. N/D No
ConfigurationVersion La versione dello schema di configurazione del proxy API a cui è conforme questo proxy API. L'unico valore supportato al momento è majorVersion 4 e minorVersion 0. Questa impostazione potrebbe essere utilizzata in futuro per consentire l'evoluzione del formato del proxy API. 4.0 No
Description Una descrizione testuale del proxy API. Se fornita, la descrizione verrà visualizzata nell'interfaccia utente di Apigee. N/D No
DisplayName Un nome intuitivo che potrebbe essere diverso dall'attributo name della configurazione del proxy API. N/D No
Policies Un elenco di criteri nella directory /policies di questo proxy API. In genere vedrai questo elemento solo quando il proxy API è stato creato utilizzando la UI di Apigee. Si tratta semplicemente di un'impostazione del manifest, progettata per fornire visibilità sui contenuti del proxy API. N/D No
ProxyEndpoints Un elenco di endpoint proxy nella directory /proxies di questo proxy API. In genere vedrai questo elemento solo quando il proxy API è stato creato utilizzando l'interfaccia utente Apigee. Si tratta semplicemente di un'impostazione del manifest, progettata per fornire visibilità ai contenuti del proxy API. N/D No
Resources Un elenco di risorse (JavaScript, Python, Java, XSLT) nella directory /resources di questo proxy API. In genere, questo elemento viene visualizzato solo quando il proxy API è stato creato utilizzando la UI di Apigee. Si tratta semplicemente di un'impostazione del manifest, progettata per fornire visibilità ai contenuti del proxy API. N/D No
Spec Identifica la specifica OpenAPI associata al proxy API. Il valore è impostato su un URL o su un percorso nel negozio delle specifiche.
 N/D No
TargetServers Un elenco dei server di destinazione a cui viene fatto riferimento in qualsiasi endpoint di destinazione di questo proxy API. In genere questo elemento viene visualizzato solo quando il proxy API è stato creato utilizzando Apigee. Si tratta semplicemente di un'impostazione del manifest, progettata per fornire visibilità sui contenuti del proxy API. N/D No
TargetEndpoints Un elenco di endpoint di destinazione nella directory /targets di questo proxy API. In genere vedrai questo elemento solo quando il proxy API è stato creato utilizzando la UI di Apigee. Si tratta semplicemente di un'impostazione del manifest, progettata per fornire visibilità ai contenuti del proxy API. N/D No

ProxyEndpoint

L'immagine seguente mostra il flusso di richiesta/risposta:

Mostra un client che chiama un servizio HTTP. La richiesta passa attraverso l&#39;endpoint proxy e poi l&#39;endpoint di destinazione prima di essere elaborata dal servizio HTTP. La risposta passa attraverso l&#39;endpoint di destinazione e poi l&#39;endpoint proxy prima di essere restituita al client.

/apiproxy/proxies/default.xml

La configurazione di ProxyEndpoint definisce l'interfaccia in entrata (rivolta al client) per un proxy API. Quando configuri un endpoint proxy, imposti una configurazione di rete che definisce in che modo le applicazioni client (app) devono richiamare l'API sottoposta a proxy.

La seguente configurazione di esempio di ProxyEndpoint verrà memorizzata in /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Gli elementi di configurazione richiesti in un endpoint proxy di base sono:

Elementi di configurazione di ProxyEndpoint

Nome Descrizione Predefinito Obbligatorio?
ProxyEndpoint
name Il nome dell'endpoint proxy. Deve essere univoco all'interno della configurazione del proxy API quando (in rari casi) vengono definiti più endpoint proxy. I caratteri che puoi utilizzare nel nome sono limitati ai seguenti: A-Za-z0-9._\-$ %. N/D Sì
PreFlow Definisce i criteri nel flusso PreFlow di una richiesta o di una risposta. N/D Sì
Flows
Definisce i criteri nei flussi condizionali di una richiesta o di una risposta.
N/D Sì
PostFlow
Definisce le policy nel flusso PostFlow di una richiesta o di una risposta.
N/D Sì
HTTPProxyConnection Definisce l'indirizzo di rete e il percorso URI associati al proxy API.
BasePath

Una stringa obbligatoria che identifica in modo univoco il percorso URI utilizzato da Apigee per indirizzare i messaggi in entrata al proxy API corretto.

BasePath è un frammento URI (ad esempio /weather) aggiunto all'URL base di un proxy API (ad esempio http://apifactory-test.apigee.net). BasePath deve essere univoco all'interno di un ambiente. L'unicità viene convalidata quando viene generato o importato un proxy API.

Utilizzo di un carattere jolly nei percorsi di base

Puoi utilizzare uno o più caratteri jolly "*" nei percorsi di base del proxy API. Ad esempio, un percorso di base /team/*/members consente ai client di chiamare https://[host]/team/blue/members e https://[host]/team/green/members senza che tu debba creare nuovi proxy API per supportare nuovi team. Tieni presente che /**/ non è supportato.

Importante:Apigee NON supporta l'utilizzo di un carattere jolly "*" come primo elemento di un percorso di base. Ad esempio, questo NON è supportato: /*/search. L'avvio del percorso di base con un carattere "*" può causare errori imprevisti a causa del modo in cui Apigee identifica i percorsi validi.

 / Sì
Properties Un insieme di impostazioni di configurazione HTTP facoltative può essere definito come proprietà di un <ProxyEndpoint>. Le proprietà disponibili includono:
  • request.queryparams.ignore.content.type.charset

    Utilizza la proprietà request.queryparams.ignore.content.type.charset per indicare al proxy di ignorare il parametro charset dell'intestazione Content-Type durante l'elaborazione dell'URL della richiesta. Ad esempio: 

    <Properties>
  <Property name="request.queryparams.ignore.content.type.charset">true</Property>
</Properties>

    La tabella seguente mostra un output di esempio a seconda dell'impostazione della proprietà charset e della presenza del parametro charset dell'intestazione Content-Type.

    Impostazione della proprietà Valore intestazione Output di esempio
    charset=false charset param not set john.doe+test@gmail.com
    charset=false charset=utf-8 john.doe test@gmail.com
    charset=true e nessun parametro charset nell'intestazione. charset param not set john.doe+test@gmail.com
    charset=true charset=utf-8 param set john.doe+test@gmail.com
  • request.payload.parse.limit

    Utilizza la proprietà request.payload.parse.limit per impostare la dimensione massima del payload che può essere elaborato nel flusso di richieste, in megabyte (M).

    Ad esempio:

    <Properties>
  <Property name="request.payload.parse.limit">30M</Property>
</Properties>

    Il limite minimo configurabile è 10 MB e il limite massimo configurabile è 30 MB. Se la proprietà non è impostata, il limite predefinito è 10 M.

    Per saperne di più, vedi Dimensioni del payload del messaggio.

 N/D No
FaultRules
Definisce il modo in cui l'endpoint proxy reagisce a un errore. Una regola di errore specifica due elementi:
  • Una condizione che specifica il guasto da gestire in base alla categoria, alla sottocategoria o al nome predefiniti del guasto
  • Una o più policy che definiscono il comportamento della regola di errore per la condizione corrispondente

Consulta la sezione Gestione degli errori.

 N/D No
DefaultFaultRule

Gestisce eventuali errori (di sistema, di trasporto, di messaggistica o di policy) che non vengono gestiti esplicitamente da un'altra regola di errore.

Consulta la sezione Gestione degli errori.

 N/D No
RouteRule Definisce la destinazione dei messaggi di richiesta in entrata dopo l'elaborazione da parte della pipeline di richiesta ProxyEndpoint. In genere, RouteRule punta a un endpoint di destinazione denominato, a un IntegrationEndpoint o a un URL.
Name Attributo obbligatorio, che fornisce un nome per RouteRule. I caratteri che puoi utilizzare nel nome sono limitati ai seguenti: A-Za-z0-9._\-$ %. Ad esempio, Cat2 %_ è un nome legale. N/D Sì
Condition Un'istruzione condizionale facoltativa utilizzata per il routing dinamico in fase di esecuzione. Le Conditional RouteRules sono utili, ad esempio, per attivare il routing basato sui contenuti per supportare il controllo delle versioni del backend. N/D No
TargetEndpoint

Una stringa facoltativa che identifica una configurazione TargetEndpoint denominata. Un endpoint di destinazione denominato è qualsiasi endpoint di destinazione definito nello stesso proxy API nella directory/targets.

Se specifichi un endpoint di destinazione, indichi dove devono essere inoltrati i messaggi di richiesta dopo l'elaborazione da parte della pipeline di richieste ProxyEndpoint. Tieni presente che questa è un'impostazione facoltativa.

Un endpoint proxy può chiamare direttamente un URL. Ad esempio, una risorsa JavaScript o Java, che funge da client HTTP, può svolgere il compito di base di un endpoint di destinazione, ovvero inoltrare le richieste a un servizio di backend.

 N/D No
URL Una stringa facoltativa che definisce un indirizzo di rete in uscita chiamato dall'endpoint proxy, ignorando qualsiasi configurazione TargetEndpoint che potrebbe essere archiviata in /targets. N/D No

Come configurare RouteRules

Un endpoint di destinazione denominato si riferisce a un file di configurazione in /apiproxy/targets a cui RouteRule inoltra una richiesta dopo l'elaborazione da parte dell'endpoint proxy.

Ad esempio, la seguente RouteRule fa riferimento alla configurazione /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Chiamata diretta dell'URL

Un endpoint proxy può anche richiamare direttamente un servizio di backend. L'invocazione diretta dell'URL ignora qualsiasi configurazione TargetEndpoint denominata in /apiproxy/targets. Per questo motivo, TargetEndpoint è una configurazione del proxy API facoltativa, anche se, in pratica, l'invocazione diretta dall'endpoint proxy non è consigliata.

Ad esempio, la seguente RouteRule esegue una chiamata HTTP a http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Route condizionali

RouteRules può essere concatenato per supportare il routing dinamico in fase di runtime. Le richieste in entrata possono essere indirizzate a configurazioni TargetEndpoint denominate, direttamente agli URL o a una combinazione dei due, in base alle intestazioni HTTP, al contenuto del messaggio, parametri di ricerca o a informazioni contestuali come l'ora del giorno, le impostazioni internazionali e così via.

Le RouteRule condizionali funzionano come altre istruzioni condizionali su Apigee. Consulta Riferimento alle condizioni e Riferimento alle variabili di flusso.

Ad esempio, la seguente combinazione RouteRule valuta innanzitutto la richiesta in entrata per verificare il valore di un'intestazione HTTP. Se l'intestazione HTTP routeTo ha il valore TargetEndpoint1, la richiesta viene inoltrata all'endpoint di destinazione denominato TargetEndpoint1. In caso contrario, la richiesta in entrata viene inoltrata a http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Percorsi nulli

È possibile definire una RouteRule null per supportare scenari in cui il messaggio di richiesta non deve essere inoltrato all'endpoint di destinazione. Ciò è utile quando l'endpoint proxy esegue tutta l'elaborazione necessaria, ad esempio utilizzando JavaScript per chiamare un servizio esterno o recuperare dati da una ricerca nell'archivio chiave/valore di Apigee.

Ad esempio, il seguente codice definisce una route nulla:

<RouteRule name="GoNowhere"/>

Le route null condizionali possono essere utili. Nell'esempio seguente, una route null è configurata per l'esecuzione quando un'intestazione HTTP request.header.X-DoNothing ha un valore diverso da null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Ricorda che le RouteRules possono essere concatenate, quindi una Route nulla condizionale in genere è un componente di un insieme di RouteRules progettate per supportare il routing condizionale.

Un utilizzo pratico di una route null condizionale è il supporto della memorizzazione nella cache. Utilizzando il valore della variabile impostata dalla norma Cache, puoi configurare un proxy API per eseguire la route null quando una voce viene pubblicata dalla cache.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

Mostra un client che chiama un servizio HTTP. La richiesta passa attraverso l&#39;endpoint proxy e poi l&#39;endpoint di destinazione prima di essere elaborata dal servizio HTTP. La risposta passa attraverso l&#39;endpoint di destinazione e poi l&#39;endpoint proxy prima di essere restituita al client.

Un endpoint di destinazione è l'equivalente in uscita di un endpoint proxy. Un endpoint di destinazione funge da client per un servizio o un'API di backend: invia richieste e riceve risposte.

Un proxy API non deve avere endpoint di destinazione. Gli endpoint proxy possono essere configurati per chiamare direttamente gli URL. Un proxy API senza endpoint di destinazione di solito contiene un endpoint proxy che chiama direttamente un servizio di backend o che è configurato per chiamare un servizio utilizzando Java o JavaScript.

Configurazione TargetEndpoint

/targets/default.xml

L'endpoint di destinazione definisce la connessione in uscita da Apigee a un altro servizio o risorsa.

Ecco una configurazione di esempio di TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <EventFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Elementi di configurazione TargetEndpoint

Un endpoint di destinazione può chiamare una destinazione in uno dei seguenti modi:

  • HTTPTargetConnection per chiamate HTTP o HTTPS
  • LocalTargetConnection per il concatenamento proxy-to-proxy locale

Configura solo uno di questi in un endpoint di destinazione.

Nome Descrizione Predefinito Obbligatorio?
TargetEndpoint
name Il nome dell'endpoint di destinazione, che deve essere univoco all'interno della configurazione del proxy API. Il nome dell'endpoint di destinazione viene utilizzato in ProxyEndpoint RouteRule per indirizzare le richieste per l'elaborazione in uscita. I caratteri che puoi utilizzare nel nome sono limitati ai seguenti: A-Za-z0-9._\-$ %. N/D Sì
PreFlow Definisce i criteri nel flusso PreFlow di una richiesta o di una risposta. N/D Sì
Flows
Definisce i criteri nei flussi condizionali di una richiesta o di una risposta.
N/D Sì
PostFlow
Definisce le policy nel flusso PostFlow di una richiesta o di una risposta.
N/D Sì
EventFlow
Definisce i criteri nel flusso EventFlow di una risposta. EventFlow viene utilizzato per lo streaming di eventi inviati dal server. Per ulteriori informazioni, vedi Eventi inviati dal server in streaming.
N/D No
HTTPTargetConnection

Con i relativi elementi secondari, specifica una risorsa di backend raggiungibile tramite HTTP.

Se utilizzi HTTPTargetConnection, non configurare altri tipi di connessioni di destinazione (ScriptTarget o LocalTargetConnection).

Puoi utilizzare l'elemento secondario <Authentication> per effettuare chiamate autenticate a servizi Google o servizi personalizzati in esecuzione su determinati prodotti Google Cloud, come Cloud Functions e Cloud Run. L'utilizzo dell'elemento <Authentication> richiede i passaggi di configurazione e deployment descritti in Utilizzo dell'autenticazione Google. Con la configurazione corretta, il criterio crea un token di autenticazione e lo aggiunge alla richiesta di servizio. Vedi anche Utilizzo dell'elemento <Authentication>.
URL Definisce l'indirizzo di rete del servizio di backend a cui l'endpoint di destinazione inoltra i messaggi di richiesta. N/D No
LoadBalancer

Definisce una o più configurazioni TargetServer denominate. Le configurazioni TargetServer denominato possono essere utilizzate per il bilanciamento del carico definendo due o più connessioni di configurazione dell'endpoint.

Puoi anche utilizzare i server di destinazione per separare le configurazioni dei proxy API dagli URL degli endpoint del servizio di backend concreti.

 N/D No
Properties Un insieme di impostazioni di configurazione HTTP facoltative può essere definito come proprietà di un <TargetEndpoint>.

Utilizza la proprietà response.payload.parse.limit per impostare la dimensione massima del payload che può essere elaborato nel flusso di risposta, in megabyte (M).

Ad esempio:

<Properties>
  <Property name="response.payload.parse.limit">15M</Property>
</Properties>

Il limite minimo configurabile è 10 MB e il limite massimo configurabile è 30 MB. Se la proprietà non è impostata, il limite predefinito è 10 M.

Per saperne di più, vedi Dimensioni del payload del messaggio.

 N/D No
SSLInfo Se vuoi, definisci le impostazioni TLS/SSL su un endpoint di destinazione per controllare la connessione TLS/SSL tra il proxy API e il servizio di destinazione. Consulta Configurazione di TargetEndpoint TLS/SSL. N/D No
LocalTargetConnection Con i relativi elementi secondari, specifica una risorsa da raggiungere localmente, ignorando le caratteristiche di rete come il bilanciamento del carico e i processori di messaggi.

Per specificare la risorsa di destinazione, includi l'elemento secondario APIProxy (con l'elemento ProxyEndpoint) o l'elemento secondario Path.

Per ulteriori informazioni, vedi Concatenamento di proxy API.

Se utilizzi LocalTargetConnection, non configurare altri tipi di connessioni di destinazione (HTTPTargetConnection o ScriptTarget).
APIProxy Specifica il nome di un proxy API da utilizzare come destinazione per le richieste. Il proxy di destinazione deve trovarsi nella stessa organizzazione e nello stesso ambiente del proxy che invia le richieste. Si tratta di un'alternativa all'utilizzo dell'elemento Percorso. N/D No
ProxyEndpoint Utilizzato con APIProxy per specificare il nome dell'endpoint proxy del proxy di destinazione. N/D No
Path Specifica il percorso dell'endpoint di un proxy API da utilizzare come destinazione per le richieste. Il proxy di destinazione deve trovarsi nella stessa organizzazione e nello stesso ambiente del proxy che invia le richieste. Questa è un'alternativa all'utilizzo di APIProxy. N/D No
FaultRules
Definisce il modo in cui l'endpoint di destinazione reagisce a un errore. Una regola di errore specifica due elementi:
  • Una condizione che specifica il guasto da gestire in base alla categoria, alla sottocategoria o al nome predefiniti del guasto
  • Una o più policy che definiscono il comportamento della regola di errore per la condizione corrispondente

Consulta la sezione Gestione degli errori.

 N/D No
DefaultFaultRule

Gestisce tutti gli errori (di sistema, di trasporto, di messaggistica o di policy) che non vengono gestiti esplicitamente da un'altra FaultRule.

Consulta la sezione Gestione degli errori.

 N/D No

Utilizzo dell'elemento <Authentication>

L'utilizzo dell'elemento <Authentication> in <TargetEndpoint> è identico all'utilizzo dell'elemento <Authentication> nelle norme ServiceCallout. Sia in <TargetEndpoint> che in ServiceCallout, <Authentication> è un sottoelemento di <HttpTargetConnection>. Per maggiori dettagli, vedi Elemento di autenticazione nel riferimento alle norme ServiceCallout.

Riferimento all'errore dell'elemento <Authentication>

Se utilizzi l'elemento <Authentication>, puoi trovare possibili messaggi di errore e suggerimenti per la risoluzione dei problemi per gli errori di deployment e di runtime nella sezione Errori della documentazione dei criteri ServiceCallout.

Esempi di elementi <Authentication>

L'esempio seguente mostra come chiamare un servizio di cui è stato eseguito il deployment su Cloud Run come destinazione utilizzando l'elemento Authentication per generare un token OpenID Connect necessario per autenticare la chiamata: 

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

L'esempio seguente mostra come chiamare un TargetService che punta a Cloud Run utilizzando l'elemento Authentication per generare un token OpenID Connect necessario per autenticare la chiamata. L'elemento HeaderName aggiunge il token di autenticazione generato a un'intestazione denominata X-Serverless-Authorization che viene inviata al sistema di destinazione. L'intestazione Authorization, se presente, viene lasciata invariata e inviata anche nella richiesta. 

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

L'esempio seguente mostra come chiamare un TargetService che punta al servizio Google Secret Manager. In questo esempio, l'elemento GoogleAccessToken è configurato per generare un token di autenticazione Google per autenticare la richiesta di destinazione: 

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

L'esempio seguente mostra come impostare automaticamente il pubblico di GoogleIDToken. Quando useTargetUrl è true e la variabile a cui viene fatto riferimento non viene risolta in una variabile valida, l'URL della destinazione (esclusi i parametri di ricerca) viene utilizzato come segmento di pubblico. Supponiamo che il percorso della richiesta sia /foobar e l'URL del server di destinazione sia https://xyz.com, il pubblico del GoogleIDToken verrà impostato automaticamente su https://xyz.com/foobar. 

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

Configurazione di TargetEndpoint TLS/SSL

Gli endpoint di destinazione spesso devono gestire connessioni HTTPS con un'infrastruttura di backend eterogenea. Per questo motivo, sono supportate diverse impostazioni di configurazione TLS/SSL.

TLS/SSL Elementi di configurazione TargetEndpoint

Nome Descrizione Predefinito Obbligatorio?
SSLInfo

Il blocco <SSLInfo> può essere utilizzato per TLS/SSL unidirezionale e bidirezionale.
Enabled

Se impostato su true, specifica che la connessione di destinazione deve utilizzare il protocollo SSL in conformità con gli altri parametri specificati in questo blocco <SSLInfo>. Se impostato su false, specifica che la connessione di destinazione non deve utilizzare SSL.

Tuttavia, se il blocco <HTTPTargetConnection> contenitore contiene un elemento <URL> che restituisce una stringa che inizia con https://, il protocollo SSL verrà utilizzato anche se <Enabled> è false. In questo caso, l'intero blocco <SSLInfo> viene ignorato.

Al contrario, se è presente un elemento <URL> che inizia con http://, il protocollo SSL non verrà utilizzato anche se <Enabled> è true.

 falso No
Enforce

Applica SSL rigoroso tra Apigee e il backend di destinazione.

Se impostato su true, le connessioni non andranno a buon fine per le destinazioni con certificati non validi, scaduti, autofirmati, con mancata corrispondenza del nome host e con una radice non attendibile. Viene restituito un codice di errore 4xx o 5xx.

Se non è impostato o è impostato su false, il risultato delle connessioni ai backend di destinazione con certificati problematici dipende dall'impostazione di <IgnoreValidationErrors> (vedi sotto). Una risposta di successo (2xx) può verificarsi in determinate condizioni, se <IgnoreValidationErrors> è impostato su true.

Puoi eseguire l'override del campo Enforce a livello di ambiente con il flag funzionalità SSLInfo.Enforce. Consulta la sezione Specifica dell'applicazione SSL a livello di ambiente.

 false No
TrustStore

Un keystore contenente certificati radice del server attendibili. Apigee tratterà il peer remoto come attendibile se la catena di certificati che invia termina con un certificato contenuto in questo archivio chiavi.

 N/D No
ClientAuthEnabled

Se impostato su true, abilita TLS bidirezionale (noto anche come mutual TLS o mTLS) tra Apigee e il peer remoto, ovvero il client API o il backend di destinazione.

L'abilitazione di TLS bidirezionale in genere richiede la configurazione di un truststore e di un keystore su Apigee.

 false No
KeyStore Un keystore contenente le chiavi private utilizzate per l'autenticazione client in uscita N/D Sì (se ClientAuthEnabled è true)
KeyAlias L'alias della chiave privata utilizzata per l'autenticazione client in uscita N/D Sì (se ClientAuthEnabled è true)
IgnoreValidationErrors

Indica se gli errori di convalida vengono ignorati. Se il sistema di backend utilizza SNI e restituisce un certificato con un nome distinto (DN) del soggetto che non corrisponde al nome host, non è possibile ignorare l'errore e la connessione non va a buon fine.

Nota: se <Enforce> è impostato su true, il valore di <IgnoreValidationErrors> viene ignorato.

 false No
Ciphers

Crittografie supportate per TLS/SSL in uscita. Se non vengono specificate cifrature, saranno consentite tutte le cifrature disponibili per la JVM.

Per limitare le cifrature, aggiungi i seguenti elementi che elencano le cifrature supportate:

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
 		N/D No
Protocols

Protocolli supportati per TLS/SSL in uscita. Se non vengono specificati protocolli, saranno consentiti tutti i protocolli disponibili per la JVM.

Per limitare i protocolli, specificali in modo esplicito. Ad esempio, per consentire solo TLS v1.2 o TLS v1.3:

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>
 		N/D No
CommonName

Apigee confronta il valore qui con il CN (Common Name) o i SAN (Subject Alternate Names) del certificato peer remoto.

 N/D No

Specifica dell'applicazione forzata del protocollo SSL a livello di ambiente

Se SSLInfo.Enforce è impostato su true o false, il valore specificato sostituisce qualsiasi opzione di applicazione granulare specificata nei blocchi <SSLInfo> nelle configurazioni TargetEndpoint o TargetServer.

Se SSLInfo.Enforce non è impostato, l'applicazione di SSL è determinata da eventuali valori specificati utilizzando l'elemento <Enforce> all'interno dei singoli blocchi <SSLInfo>. Per ulteriori informazioni, consulta Configurazione di TargetEndpoint TLS/SSL.

Nel seguente esempio, SSLInfo.Enforce è impostato su true. Nell'output risultante, puoi notare che SSL è applicato nell'ambiente specificato.

VALUE=true
curl -Ss -v -X PUT \
    "https://apigee.googleapis.com/v1/organizations/MYORG/environments/MYENV" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer TOKEN" \
    -d '{
        "name": "MYENV",
        "properties": {
            "property": [{
                "name": "features.SSLInfo.Enforce",
                "value": "'"$VALUE"'"
            }]
        }
    }'

Output:

{
  ...
  "properties": {
    "property": [
      {
        "name": "features.SSLInfo.Enforce",
        "value": "true"
      }
    ]
  },
  ...
}

Esempio di endpoint di destinazione con autenticazione client in uscita abilitata

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Per istruzioni dettagliate, vedi Opzioni per la configurazione di TLS.

Utilizzo delle variabili di flusso per impostare dinamicamente i valori TLS/SSL

Puoi anche impostare dinamicamente i dettagli TLS/SSL per supportare requisiti di runtime flessibili. Ad esempio, se il proxy si connette a due target potenzialmente diversi (un target di test e un target di produzione), puoi fare in modo che il proxy API rilevi a livello di programmazione l'ambiente che sta chiamando e imposti dinamicamente i riferimenti all'archivio chiavi e all'archivio attendibile appropriati. L'articolo della community Apigee Dynamic SSLInfo for TargetEndpoint using variable reference spiega questo scenario in modo più dettagliato e fornisce esempi di proxy API implementabili.

Nell'esempio seguente di come impostare il tag <SSLInfo> in una configurazione TargetEndpoint, i valori possono essere forniti in fase di runtime, ad esempio da un callout Java, da un criterio JavaScript o da un criterio AssignMessage. Utilizza le variabili del messaggio che contengono i valori che vuoi impostare.

Le variabili sono consentite solo nei seguenti elementi.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Utilizzo di riferimenti per impostare dinamicamente i valori TLS/SSL

Quando configuri un endpoint di destinazione che utilizza HTTPS, devi considerare il caso in cui il certificato TLS/SSL scade o una modifica alla configurazione del sistema richiede l'aggiornamento del certificato.

Per maggiori informazioni, vedi Gestione dei certificati scaduti.

Tuttavia, puoi configurare facoltativamente l'endpoint di destinazione in modo che utilizzi un riferimento al keystore o al truststore. Il vantaggio di utilizzare un riferimento è che puoi aggiornarlo in modo che punti a un keystore o un truststore diverso per aggiornare il certificato TLS/SSL senza dover riavviare i processori di messaggi.

Ad esempio, di seguito è riportato un endpoint di destinazione che utilizza un riferimento al keystore:

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Utilizza la seguente chiamata API POST per creare il riferimento denominato keystoreref:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

Dove $TOKEN è impostato sul tuo token di accesso OAuth 2.0, come descritto in Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl utilizzate in questo esempio, consulta la sezione Utilizzare curl. Per una descrizione delle variabili di ambiente che puoi utilizzare, consulta Impostazione delle variabili di ambiente per le richieste API Apigee.

Il riferimento specifica il nome del keystore e il relativo tipo.

Utilizza la seguente chiamata API GET per visualizzare il riferimento:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Dove $TOKEN è impostato sul tuo token di accesso OAuth 2.0, come descritto in Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl utilizzate in questo esempio, consulta la sezione Utilizzare curl. Per una descrizione delle variabili di ambiente che puoi utilizzare, consulta Impostazione delle variabili di ambiente per le richieste API Apigee.

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Dove $TOKEN è impostato sul tuo token di accesso OAuth 2.0, come descritto in Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl utilizzate in questo esempio, consulta la sezione Utilizzare curl. Per una descrizione delle variabili di ambiente che puoi utilizzare, consulta Impostazione delle variabili di ambiente per le richieste API Apigee.

Per modificare in un secondo momento il riferimento in modo che punti a un keystore diverso, assicurandoti che l'alias abbia lo stesso nome, utilizza la seguente chiamata PUT:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

Dove $TOKEN è impostato sul tuo token di accesso OAuth 2.0, come descritto in Ottenere un token di accesso OAuth 2.0. Per informazioni sulle opzioni curl utilizzate in questo esempio, consulta la sezione Utilizzare curl. Per una descrizione delle variabili di ambiente che puoi utilizzare, consulta Impostazione delle variabili di ambiente per le richieste API Apigee.

TargetEndpoint con bilanciamento del carico target

Gli endpoint di destinazione supportano il bilanciamento del carico su più server di destinazione denominati utilizzando tre algoritmi di bilanciamento del carico.

Per istruzioni dettagliate, consulta Bilanciamento del carico tra server di backend.

IntegrationEndpoint

Un IntegrationEndpoint è un endpoint di destinazione che esegue specificamente integrazioni Apigee. Se hai configurato un IntegrationEndpoint, Apigee invia l'oggetto request alla piattaforma di integrazione di Apigee per l'esecuzione. Per eseguire l'integrazione, oltre a configurare IntegrationEndpoint, devi anche aggiungere il criterio SetIntegrationRequest nel flusso del proxy.

Puoi configurare l'integrazione in modo che venga eseguita in modo sincrono o asincrono impostando l'elemento <AsyncExecution> nella configurazione IntegrationEndpoint. Per saperne di più, vedi Esecuzione sincrona e asincrona. Dopo aver eseguito l'integrazione, Apigee salva la risposta nel messaggio di risposta.

Configurazione di IntegrationEndpoint

Per configurare un endpoint di integrazione come endpoint di destinazione, aggiungi l'elemento IntegrationEndpoint alla configurazione di ProxyEndpoint. Di seguito è riportata una configurazione di esempio di ProxyEndpoint:

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

Nella configurazione di esempio di ProxyEndpoint, Apigee esegue le seguenti attività:

  1. In PreFlow, esegue il criterio denominato my-set-integration-request-policy, che imposta le variabili dell'oggetto richiesta di integrazione e del flusso di integrazione.
  2. Utilizza my-int-endpoint come endpoint di destinazione, come specificato in RouteRule.
  3. Legge l'oggetto della richiesta di integrazione creato da my-set-integration-request-policy.
  4. Invia la richiesta alla piattaforma di integrazione di Apigee utilizzando l'oggetto richiesta e le variabili di flusso impostate dal criterio SetIntegrationRequest.
  5. Salva la risposta dell'integrazione nel messaggio di risposta.

Il file XML contenente la dichiarazione <IntegrationEndpoint> sarà disponibile nella directory APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/. Se crei il proxy API utilizzando l'opzione Develop > API Proxies > CREATE NEW > Integration target, Apigee memorizza la dichiarazione nel file /apiproxy/integration-endpoints/default.xml. Se crei il file XML dell'endpoint di integrazione dall'interfaccia utente, puoi fornire un nome personalizzato per il file XML.

L'esempio seguente mostra la dichiarazione dell'elemento <IntegrationEndpoint> nel file XML:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

Elementi di configurazione di IntegrationEndpoint

Nome Descrizione Predefinito Obbligatorio?
IntegrationEndpoint
name Il nome di IntegrationEndpoint. I caratteri che puoi utilizzare nel nome sono limitati a: A-Za-z0-9._\-$ % N/D Sì
AsyncExecution Un valore booleano che specifica se l'integrazione deve essere eseguita in modalità sincrona o asincrona. Per saperne di più, vedi Esecuzione sincrona e asincrona. falso No

Esecuzione sincrona e asincrona

Puoi configurare l'integrazione in modo che venga eseguita in modalità sincrona o asincrona. Per comprendere la differenza tra le modalità di esecuzione sincrona e asincrona, consulta <AsyncExecution>.

Utilizza l'elemento <AsyncExecution> all'interno di </IntegrationEndpoint> per specificare l'esecuzione sincrona o asincrona. Se imposti <AsyncExecution> su true, l'integrazione viene eseguita in modo asincrono. Se lo imposti su false, l'integrazione viene eseguita in modo sincrono.

L'esempio seguente imposta AsyncExecution su true:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

Norme

La directory /policies in un proxy API contiene tutte le policy disponibili da allegare ai flussi nel proxy API.

Elementi di configurazione delle policy

Nome Descrizione Predefinito Obbligatorio?
Policy
name

Il nome interno del criterio. I caratteri che puoi utilizzare nel nome sono limitati a: A-Za-z0-9._\-$ %. Tuttavia, la UI di Apigee applica ulteriori limitazioni, ad esempio la rimozione automatica dei caratteri non alfanumerici.

(Facoltativo) Utilizza l'elemento <DisplayName> per etichettare il proxy del criterio nell'editor dell'interfaccia utente di Apigee con un nome diverso in linguaggio naturale.

 N/D Sì
enabled

Imposta true per applicare la policy.

Imposta false su Off per disattivare il criterio. La norma non verrà applicata anche se rimane allegata a un flusso.

 true No
continueOnError

Imposta questo valore su false per restituire un errore quando un criterio non viene rispettato. Questo è il comportamento previsto per la maggior parte delle norme.

Imposta su true per continuare l'esecuzione del flusso anche dopo l'esito negativo di un criterio.

 false No
async

Se impostato su true, l'esecuzione dei criteri viene scaricata su un altro thread, lasciando il thread principale libero di gestire richieste aggiuntive. Al termine dell'elaborazione offline, il thread principale torna e termina la gestione del flusso di messaggi. In alcuni casi, l'impostazione di async su true migliora le prestazioni del proxy API. Tuttavia, l'uso eccessivo di async può influire negativamente sulle prestazioni con un numero eccessivo di cambi di thread.

Per utilizzare il comportamento asincrono nei proxy API, consulta Modello oggetto JavaScript.

 false No

Allegato delle norme

L'immagine seguente mostra la sequenza di esecuzione dei flussi del proxy API:

mostra un client che chiama un servizio HTTP. La richiesta incontra l&#39;endpoint proxy e l&#39;endpoint di destinazione, ognuno dei quali contiene passaggi che attivano i criteri. Dopo che il servizio HTTP restituisce la risposta, questa viene elaborata dall&#39;endpoint di destinazione e poi da ProxyEndpoint prima di essere restituita al client. Come per la richiesta, la risposta viene elaborata dalle norme all&#39;interno dei passaggi.

Come mostrato sopra:

I criteri vengono allegati come passaggi di elaborazione ai flussi. Il nome del criterio viene utilizzato per fare riferimento al criterio da applicare come passaggio di elaborazione. Il formato di un allegato di norme è il seguente:

<Step><Name>MyPolicy</Name></Step>

I criteri vengono applicati nell'ordine in cui sono associati a un flusso. Ad esempio:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Elementi di configurazione dell'associazione delle policy

Nome Descrizione Predefinito Obbligatorio?
Step
Name Il nome della norma da eseguire in base a questa definizione del passaggio. N/D Sì
Condition Un'istruzione condizionale che determina se il criterio viene applicato o meno. Se una policy ha una condizione associata, viene eseguita solo se l'istruzione condizionale restituisce il valore true. N/D No

Flussi

ProxyEndpoint e TargetEndpoint definiscono una pipeline per l'elaborazione dei messaggi di richiesta e risposta. Una pipeline di elaborazione è costituita da un flusso di richiesta e da un flusso di risposta. Ogni flusso di richiesta e flusso di risposta è suddiviso in un PreFlow, uno o più flussi condizionali o denominati facoltativi e un PostFlow.

  • PreFlow: viene sempre eseguito. Viene eseguito prima di qualsiasi flusso condizionale.
  • PostFlow: viene sempre eseguito. Viene eseguito dopo qualsiasi flusso condizionale.

Inoltre, puoi aggiungere un PostClientFlow all'endpoint proxy, che viene eseguito dopo che la risposta viene restituita all'app client richiedente. A questo flusso può essere collegata solo la norma MessageLogging. PostClientFlow riduce la latenza del proxy API e rende disponibili le informazioni per la registrazione che non vengono calcolate fino a quando la risposta non viene restituita al client, ad esempio client.sent.start.timestamp e client.sent.end.timestamp.Il flusso viene utilizzato principalmente per misurare l'intervallo di tempo tra i timestamp di inizio e fine del messaggio di risposta.

Ecco un esempio di PostClientFlow con un criterio di registrazione dei messaggi allegato.

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

La pipeline di elaborazione del proxy API esegue i flussi nella seguente sequenza:

Pipeline di richiesta:

  1. PreFlow della richiesta proxy
  2. Flussi condizionali di richiesta proxy (facoltativo)
  3. PostFlow della richiesta proxy
  4. Target Request PreFlow
  5. Flussi condizionali delle richieste target (facoltativo)
  6. Target Request PostFlow

Pipeline di risposta:

  1. Target Response PreFlow
  2. Flussi condizionali di risposta target (facoltativo)
  3. Target Response PostFlow
  4. Proxy Response PreFlow
  5. Flussi condizionali di risposta del proxy (facoltativo)
  6. Proxy Response PostFlow
  7. PostClientFlow Response (facoltativo)

Solo i flussi con allegati di criteri devono essere configurati nelle configurazioni ProxyEndpoint o TargetEndpoint. PreFlow e PostFlow devono essere specificati in una configurazione ProxyEndpoint o TargetEndpoint solo quando è necessario applicare un criterio durante l'elaborazione di PreFlow o PostFlow.

A differenza dei flussi condizionali, l'ordine degli elementi PreFlow e PostFlow non è importante: il proxy API eseguirà sempre ciascun elemento nel punto appropriato della pipeline, indipendentemente dalla posizione in cui vengono visualizzati nella configurazione dell'endpoint.

Flussi condizionali

Gli endpoint proxy e gli endpoint di destinazione supportano un numero illimitato di flussi condizionali (noti anche come flussi denominati).

Il proxy API verifica la condizione specificata nel flusso condizionale e, se la condizione è soddisfatta, i passaggi di elaborazione nel flusso condizionale vengono eseguiti dal proxy API. Se la condizione non è soddisfatta, i passaggi di elaborazione nel flusso condizionale vengono ignorati. I flussi condizionali vengono valutati nell'ordine definito nel proxy API e viene eseguito il primo la cui condizione è soddisfatta.

Definendo i flussi condizionali, puoi applicare i passaggi di elaborazione in un proxy API in base a:

  • URI di richiesta
  • Verbo HTTP (GET/PUT/POST/DELETE)
  • Valore di un parametro di query, di un'intestazione e di un parametro del modulo
  • Molti altri tipi di condizioni

Ad esempio, il seguente flusso condizionale specifica che viene eseguito solo quando il percorso della risorsa della richiesta è /accesstoken. Qualsiasi richiesta in entrata con il percorso /accesstoken causa l'esecuzione di questo flusso, insieme a tutte le norme associate al flusso. Se il percorso della richiesta non include il suffisso /accesstoken, il flusso non viene eseguito (anche se potrebbe essere eseguito un altro flusso condizionale).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>

Elementi di configurazione del flusso

Nome Descrizione Predefinito Obbligatorio?
Flow Una pipeline di elaborazione di richieste o risposte definita da un endpoint proxy o endpoint di destinazione
Name Il nome univoco del flusso. N/D Sì
Condition Un'istruzione condizionale che valuta una o più variabili per restituire true o false. Tutti i flussi diversi dai tipi PreFlow e PostFlow predefiniti devono definire una condizione per la loro esecuzione. Tuttavia, se includi un singolo flusso senza una condizione alla fine di una sequenza di flussi, questo fungerà da istruzione "Else" alla fine della sequenza di flussi. N/D Sì
Request La pipeline associata all'elaborazione dei messaggi di richiesta N/D No
Response La pipeline associata all'elaborazione del messaggio di risposta N/D No

Elaborazione dei passaggi

L'ordine sequenziale dei flussi condizionali viene applicato da Apigee. I flussi condizionali vengono eseguiti dall'alto verso il basso. Viene eseguito il primo flusso condizionale la cui condizione restituisce true e viene eseguito un solo flusso condizionale.

Ad esempio, nella seguente configurazione di Flow, qualsiasi richiesta in entrata che non includa il suffisso del percorso /first o /second causerà l'esecuzione di ThirdFlow, applicando il criterio denominato Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Risorse

Le "risorse" (file di risorse da utilizzare nei proxy API) sono script, codice e trasformazioni XSL che possono essere allegati ai flussi utilizzando i criteri. Questi vengono visualizzati nella sezione Script dell'editor proxy API nell'interfaccia utente di Apigee.

Consulta la sezione Gestione delle risorse per i tipi di risorse supportati.

Le risorse possono essere archiviate in un proxy API, un ambiente o un'organizzazione. In ogni caso, una risorsa viene a cui viene fatto riferimento per nome in un criterio. Apigee risolve il nome passando dal proxy API all'ambiente e poi all'organizzazione.

A una risorsa archiviata a livello di organizzazione è possibile fare riferimento tramite i criteri in qualsiasi ambiente. A una risorsa archiviata a livello di ambiente è possibile fare riferimento nei criteri di quell'ambiente. Una risorsa archiviata a livello di proxy API può essere referenziata solo dai criteri in quel proxy API.