Informazioni sulle route

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Una route determina il percorso di una richiesta da ProxyEndpoint a TargetEndpoint. La route include l'URL utilizzato per accedere a ProxyEndpoint dell'API e l'URL del servizio di backend definito da TargetEndpoint.

Determinare l'URL dell'endpoint proxy API

L'immagine seguente mostra una richiesta in arrivo a ProxyEndpoint da un'app, che viene indirizzata al servizio di backend:

Dopo aver creato un proxy API su Edge, l'URL predefinito utilizzato da un'app per accedere al proxy ha il seguente formato:

http://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

https://{org-name}-{env-name}.apigee.net/{base-path}/{resource-path}

dove:

• {org-name} è il nome della tua organizzazione. Questo nome viene creato quando crei un account su Edge.
• {env-name} è il nome dell'ambiente perimetrale. Per impostazione predefinita, a tutte le organizzazioni Apigee create nel cloud viene eseguito il provisioning di due ambienti: "test" e "prod". Quando esegui il deployment di un proxy API, puoi scegliere di eseguirne il deployment in uno o entrambi gli ambienti.
• {base-path} e {resource-path} vengono definiti quando crei il proxy API.

Quando arriva una richiesta a Edge, Edge analizza l'URL per indirizzarla al ProxyEndpoint corretto. Ad esempio, il seguente URL viene utilizzato per accedere a un proxy API su Edge:

http://myOrg-prod.apigee.net/v1/weather/forecastrss

Se esamini la definizione di ProxyEndpoint per il proxy API nella figura precedente, puoi vedere come questo URL viene analizzato da Edge:

1. La parte del dominio dell'URL, http://myOrg-prod.apigee.net, corrisponde a un host virtuale su Edge. Nella definizione ProxyEndpoint di cui sopra, il proxy API utilizza il tag <VirtualHost> per fare riferimento a un host virtuale denominato default. Nel tuo ambiente possono essere definiti più host virtuali.
   
   Un host virtuale definisce i domini e le porte su cui è esposto un proxy API. Un host virtuale definisce inoltre se si accede al proxy API tramite il protocollo HTTP o il protocollo HTTPS criptato. Per informazioni dettagliate sugli host virtuali, consulta l'articolo Informazioni sugli host virtuali (beta).
2. La seconda parte dell'URL, /v1/weather, è determinata dall'elemento <BasePath> in ProxyEndpoint. Il percorso di base deve essere univoco per il proxy API per l'ambiente, in modo che due proxy API non abbiano lo stesso percorso di base.
3. La terza parte dell'URL, /forecastrss, è una risorsa definita dal proxy API con il flusso condizionale corrispondente definito dal tag <Flows>.

Determinazione dell'URL dell'endpoint di destinazione

Il tag <RouteRule> in una definizione di ProxyEndpoint determina la destinazione del proxy API e viene valutato dopo che sono stati elaborati tutti i criteri dei criteri PreFlow, Conditional Flow e PostFlow della richiesta ProxyEndpoint.

Un ProxyEndpoint può definire la destinazione come:

• Un URL diretto a un servizio di backend.
• Una singola definizione TargetEndpoint.
• Più TargetEndpoint in cui il proxy API delega la richiesta a un endpoint di destinazione in base a una condizione.
• Route o target nulli, ovvero che la richiesta non viene inoltrata a una destinazione. Invece, l'intera elaborazione della richiesta e la generazione della risposta avvengono su Edge.

URL diretto

Un ProxyEndpoint può richiamare direttamente un servizio di backend, ignorando qualsiasi configurazione TargetEndpoint denominata. Ad esempio, la seguente risorsa <RouteRule> effettua sempre una chiamata HTTP a http://api.mycompany.com/myAPI:

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

Tuttavia, poiché non esiste un TargetEndpoint, puoi aggiungere criteri solo ai flussi definiti da ProxyEndpoint.

Destinazione singola

In una singola definizione di destinazione, ProxyEndpoint fa riferimento a una singola definizione TargetEndpoint per nome, come mostrato nella figura sopra:

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

Tutte le richieste a questo proxy API vengono indirizzate alla stessa definizione di TargetEndpoint. Il tag <URL> in TargetEndpoint determina la posizione del servizio di backend. Nella figura precedente, l'URL di destinazione è http://weather.yahooapis.com.

Target condizionali

Il tag <RouteRule> consente di indirizzare una richiesta a una destinazione in base a una condizione. Puoi utilizzare variabili di flusso, parametri di query, intestazioni HTTP, contenuti dei messaggi o informazioni contestuali come ora del giorno e impostazioni internazionali per determinare l'endpoint di destinazione. Ad esempio, potresti includere un'area geografica, come US e UK, in un URL di richiesta. Puoi quindi instradare una richiesta a un endpoint di destinazione in base alla regione.

La seguente regola di route valuta un'intestazione HTTP in una richiesta. Se l'intestazione HTTP routeTo ha il valore TargetEndpoint1, la richiesta viene inoltrata a TargetEndpoint denominato TargetEndpoint1. In caso contrario, la richiesta viene inoltrata a TargetEndpoint2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
 <TargetEndpoint>TargetEndpoint2</TargetEndpoint>
</RouteRule>

Se disponi di più regole di route, creane una come "predefinita", ovvero come regola di route senza condizione. Assicurati che la regola di route predefinita sia definita per ultima nell'elenco delle route condizionali poiché le regole vengono valutate dall'alto verso il basso in ProxyEndpoint.

Vedi anche Route condizionali e Riferimento per le condizioni.

Route nulla

Una route nulla supporta scenari in cui il messaggio della richiesta non deve essere inoltrato a un TargetEndpoint. Questo è utile quando ProxyEndpoint esegue tutte le elaborazioni necessarie, ad esempio utilizzando JavaScript per chiamare un servizio esterno.

L'esempio seguente definisce una route nulla:

<RouteRule name="GoNowhere"/>

Scopri di più

• Informazioni sugli host virtuali
• Riferimento per la configurazione del proxy API
• Riferimento alle proprietà degli endpoint
• Bilanciamento del carico tra server di backend