Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. info
Una route determina il percorso di una richiesta dal ProxyEndpoint al TargetEndpoint. Nel percorso è incluso l'URL utilizzato per accedere all'API ProxyEndpoint e l'URL del servizio di backend definito da TargetEndpoint.
Guarda questo video per un'introduzione ai route, che descrive la relazione tra ProxyEndpoint e TargetEndpoint.
Determinazione dell'URL dell'endpoint del proxy API
L'immagine seguente mostra una richiesta in arrivo a ProxyEndpoint da un'app e la richiesta 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 Edge. Per impostazione predefinita, per 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 eseguirlo in uno o in entrambi gli ambienti.
- {base-path} e {resource-path} vengono definiti quando crei il proxy API.
Quando Edge riceve una richiesta, la analizza per indirizzarla all'endpoint proxy 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 dell'API nella figura sopra, puoi vedere come questo URL viene analizzato da Edge:
- La parte del dominio dell'URL, http://myOrg-prod.apigee.net, corrisponde
a un host virtuale su Edge. Nella definizione di ProxyEndpoint riportata sopra, il proxy dell'API
utilizza il tag <VirtualHost> per fare riferimento a un host virtuale denominato default. Nel tuo ambiente puoi definire più host virtuali.
Un host virtuale definisce i domini e le porte su cui è esposto un proxy API. Un host virtuale definisce anche se è possibile accedere al proxy API mediante il protocollo HTTP o il protocollo HTTPS criptato. Per informazioni dettagliate sugli host virtuali, vedi Informazioni sugli host virtuali (beta). - 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.
- La terza parte dell'URL, /forecastrss, è una risorsa definita dal proxy dell'API con il flusso condizionale corrispondente definito dal tag <Flows>.
Video: guarda un breve video per saperne di più sugli endpoint del proxy API.
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 tutti i criteri in PreFlow, Flussi condizionali e PostFlow della richiesta ProxyEndpoint sono stati elaborati.
Un ProxyEndpoint può definire il target come:
- Un URL diretto a un servizio di backend.
- Una singola definizione di TargetEndpoint.
- Più TargetEndpoint in cui il proxy API delega la richiesta a un endpoint di destinazione in base a una condizione.
- Percorso o target nullo, il che significa che la richiesta non viene inoltrata a un target. Invece, l'elaborazione della richiesta e la generazione della risposta avvengono su Edge.
Video: guarda un breve video per saperne di più sugli endpoint target.
URL diretto
Un ProxyEndpoint può richiamare direttamente un servizio di backend, bypassando qualsiasi configurazione TargetEndpoint denominata. Ad esempio, il seguente <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 TargetEndpoint, puoi aggiungere criteri solo ai flussi definiti da ProxyEndpoint.
Destinazione singola
In una singola definizione del target, ProxyEndpoint fa riferimento a una singola definizione di 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 sopra, l'URL di destinazione è http://weather.yahooapis.com.
Target condizionali
Il tag <RouteRule> consente di indirizzare una richiesta a un target in base a una condizione. Per determinare l'endpoint di destinazione, puoi utilizzare variabili di flusso, parametri di query, intestazioni HTTP, contenuti dei messaggi o informazioni contestuali come ora del giorno e impostazioni internazionali. Ad esempio, in un URL richiesta potresti includere un'area geografica, come Stati Uniti e Regno Unito. Puoi quindi indirizzare 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 all'endpoint di destinazione 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 hai più regole di routing, creane una come "predefinita", ovvero come regola di routing senza condizioni. Assicurati che la regola di route predefinita sia definita per ultima nell'elenco delle route condizionali perché le regole vengono valutate dall'alto verso il basso in ProxyEndpoint.
Consulta anche Percorsi agevolati e Riferimento alle condizioni.
Video: guarda un breve video per scoprire come indirizzare a un endpoint target utilizzando i target condizionali.
Percorso nullo
Un percorso nullo supporta gli scenari in cui il messaggio di richiesta non deve essere inoltrato a un endpoint di destinazione. Questo è utile quando ProxyEndpoint esegue tutta l'elaborazione necessaria, ad esempio utilizzando JavaScript per chiamare un servizio esterno.
L'esempio seguente definisce un percorso nullo:
<RouteRule name="GoNowhere"/>