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 utilizza 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 a 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:

• Utilizza l'interfaccia utente o l'API di Apigee.
• Scarica il bundle di configurazione del proxy API, modificalo manualmente e carica la nuova configurazione in Apigee, come descritto in Download e caricamento di un pacchetto di configurazione di proxy API.

Struttura della directory di configurazione del proxy API

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

Una configurazione del proxy API è composta dai seguenti contenuti:

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

ProxyEndpoint

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

/apiproxy/proxies/default.xml

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

La seguente configurazione di ProxyEndpoint di esempio 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 obbligatori in un endpoint proxy di base sono:

Elementi di configurazione di ProxyEndpoint

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

Come configurare RouteRules

Un endpoint target denominato fa riferimento 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 regola di routing fa riferimento alla configurazione /apiproxy/targets/myTarget.xml:

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

Richiamo dell'URL diretto

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

Ad esempio, la seguente regola di route effettua una chiamata HTTP a http://api.mycompany.com/v2.

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

Route condizionali

Le regole di routing possono essere collegate in serie per supportare il routing dinamico in fase di esecuzione. Le richieste in entrata possono essere indirizzate a configurazioni di endpoint di destinazione denominate, direttamente a URL o a una combinazione di entrambi, in base alle intestazioni HTTP, ai contenuti dei messaggi, parametri di ricerca o a informazioni contestuali come l'ora del giorno, le impostazioni internazionali e così via.

Le regole di route condizionali funzionano come le altre istruzioni condizionali su Apigee. Consulta Riferimenti alle condizioni e Riferimenti alle variabili di flusso.

Ad esempio, la seguente combinazione di 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 nominato 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 null

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

Ad esempio, quanto segue definisce una Route nulla:

<RouteRule name="GoNowhere"/>

I percorsi nulli condizionali possono essere utili. Nell'esempio seguente, è configurata una route null per essere eseguita 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 regole di routing possono essere concatenate, quindi un percorso nullo condizionale è in genere un componente di un insieme di regole di routing progettate per supportare il routing condizionale.

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

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

TargetEndpoint

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 in genere contiene un endpoint proxy che chiama direttamente un servizio di backend o è configurato per chiamare un servizio utilizzando Java o JavaScript.

Configurazione di TargetEndpoint

/targets/default.xml

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

Ecco un esempio di configurazione di TargetEndpoint:

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

Elementi di configurazione di TargetEndpoint

Un endpoint target può chiamare un target in uno dei seguenti modi:

• HTTPTargetConnection per le chiamate HTTP o HTTPS
• LocalTargetConnection per l'incatenamento di proxy locali

Configurane solo uno in un endpoint target.

Utilizzo dell'elemento <Authentication>

Riferimento all'errore dell'elemento <Authentication>

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

Esempi di elementi <Authentication>

L'esempio seguente mostra come chiamare un servizio di destinazione di cui è stato eseguito il deployment su Cloud Run 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 accesso generato a un'intestazione denominata X-Serverless-Authorization 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 rimanda al servizio Secret Manager di Google. 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 segmento di pubblico del token GoogleID. Quando useTargetUrl è true e la variabile a cui si fa riferimento non risolve in una variabile valida, l'URL del target (esclusi i parametri di query) 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 di 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 devono spesso 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 di TargetEndpoint

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.2</Protocol>
 <Protocol>TLSv1.3</Protocol>
</Protocols>

Endpoint di destinazione di esempio 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 in modo programmatico l'ambiente che sta chiamando e imposta dinamicamente i riferimenti al keystore e al truststore 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 di cui è possibile eseguire il deployment.

Nel seguente esempio di come il tag <SSLInfo> viene impostato in una configurazione di TargetEndpoint, i valori possono essere forniti in fase di esecuzione, ad esempio da un callout Java, un criterio JavaScript o un criterio AssignMessage. Utilizza le variabili messaggio che contengono i valori da 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 scada o una modifica alla configurazione di sistema richieda l'aggiornamento del certificato.

Per ulteriori informazioni, consulta la sezione Gestire i certificati scaduti.

Tuttavia, se vuoi, puoi configurare l'endpoint di destinazione in modo che utilizzi un riferimento al keystore o al truststore. Il vantaggio dell'utilizzo di un riferimento è che puoi aggiornarlo in modo che punti a un keystore o truststore diverso per aggiornare il certificato TLS/SSL senza dover riavviare i Message Processor.

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/{org}/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 Utilizzare curl. Per una descrizione delle variabili di ambiente utilizzate, consulta Impostazione delle variabili di ambiente per le richieste dell'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/{org}/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 Utilizzare curl. Per una descrizione delle variabili di ambiente utilizzate, consulta Impostazione delle variabili di ambiente per le richieste dell'API Apigee.

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/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 Utilizzare curl. Per una descrizione delle variabili di ambiente utilizzate, consulta Impostazione delle variabili di ambiente per le richieste dell'API Apigee.

Per modificare in un secondo momento il riferimento in modo che indichi un altro keystore, assicurati che l'alias abbia lo stesso nome, quindi utilizza la seguente chiamata PUT:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{org}/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 Utilizzare curl. Per una descrizione delle variabili di ambiente utilizzate, consulta Impostazione delle variabili di ambiente per le richieste dell'API Apigee.

TargetEndpoint con bilanciamento del carico target

Gli endpoint target supportano il bilanciamento del carico su più server target 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 in modo specifico le 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 proxy.

Puoi configurare l'integrazione in modo che venga eseguita in modo sincrono o asincrono impostando l'elemento <AsyncExecution> nella configurazione di IntegrationEndpoint. Per ulteriori informazioni, consulta 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 è riportato un esempio di configurazione 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 ProxyEndpoint di esempio, Apigee esegue le seguenti attività:

1. In PreFlow, esegue il criterio denominato my-set-integration-request-policy, che imposta l'oggetto della richiesta di integrazione e le variabili 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 l'endpoint XML 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

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 tutti i criteri disponibili per essere collegati ai flussi nel proxy API.

Elementi di configurazione delle policy

Allegato delle norme

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

Come mostrato sopra:

I criteri vengono collegati 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 delle 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 degli allegati delle norme

Flusso

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

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

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 associato solo il MessageLogging policy. PostClientFlow riduce la latenza del proxy API e rende disponibili per il logging informazioni 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 di 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. (Facoltativo) Flussi condizionali delle richieste proxy
3. PostFlow della richiesta proxy
4. Preflight della richiesta target
5. (Facoltativo) Flussi condizionali della richiesta target
6. PostFlow della richiesta target

Pipeline di risposta:

1. PreFlow di risposta target
2. (Facoltativo) Flussi condizionali di risposta target
3. PostFlow di risposta target
4. PreFlow della risposta proxy
5. (Facoltativo) Flussi condizionali di risposta proxy
6. PostFlow della risposta proxy
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 di 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 da dove appaiono nella configurazione dell'endpoint.

Flussi condizionali

Gli endpoint proxy e 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.

Se definisci 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 di modulo
• Molti altri tipi di condizioni

Ad esempio, il seguente flusso condizionale specifica che viene eseguito solo quando il percorso della risorsa richiesta è /accesstoken. Qualsiasi richiesta in entrata con il percorso /accesstoken provoca l'esecuzione di questo flusso, insieme a eventuali criteri associati. 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

Elaborazione dei passaggi

L'ordinamento sequenziale dei flussi condizionali è imposto da Apigee. I flussi condizionali vengono eseguiti dall'alto verso il basso. Viene eseguito il primo flusso condizionale la cui condizione ha valore true e viene eseguito un solo flusso condizionale.

Ad esempio, nella seguente configurazione del flusso, qualsiasi richiesta in entrata che non include 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

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

Consulta Gestire le risorse per i tipi di risorse supportati.

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

Una risorsa archiviata a livello di organizzazione può essere richiamata dai criteri in qualsiasi ambiente. Una risorsa archiviata a livello di ambiente può essere richiamata dai criteri in quell'ambiente. È possibile fare riferimento a una risorsa memorizzata a livello di proxy API solo dai criteri in quel proxy API.