Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
Documentazione di Apigee X. Informazioni
Una route determina il percorso di una richiesta dal ProxyEndpoint al TargetEndpoint. Nella route sono inclusi l'URL utilizzato per accedere all'API ProxyEndpoint e l'URL del backend definito dal TargetEndpoint.
Guarda questo video per un'introduzione agli itinerari, che descrive il rapporto tra ProxyEndpoint e il TargetEndpoint.
Determinazione dell'URL del proxy API endpoint
L'immagine seguente mostra una richiesta in arrivo al ProxyEndpoint da un'app e 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 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} è Nome ambiente perimetrale. Per impostazione predefinita, tutte le organizzazioni Apigee create nel cloud sottoposto a provisioning con 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 {base-path} sono definiti quando crei il proxy API.
Quando arriva una richiesta a Edge, Edge analizza l'URL per indirizzarla all'URL ProxyEndpoint. 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 sopra, puoi vedere modalità di analisi dell'URL da parte di Edge:
- La parte del dominio dell'URL, http://myOrg-prod.apigee.net, corrisponde
a un host virtuale su Edge. Nella definizione di ProxyEndpoint precedente, il proxy API
utilizza il tag <VirtualHost> per
fare riferimento a un host virtuale denominato default. Puoi disporre di più istanze
host definiti nel tuo ambiente.
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 utilizzando il protocollo HTTP o protocollo HTTPS. Per informazioni dettagliate sugli host virtuali, vedi Informazioni sugli host virtuali (beta). - La seconda parte dell'URL, /v1/weather, è determinata dalla variabile <BasePath> in ProxyEndpoint. Il percorso di base deve essere univoco per il proxy API per l'ambiente, I proxy API non hanno lo stesso percorso di base.
- La terza parte dell'URL, /forecastrss, è una risorsa definita dalla Proxy 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 un La definizione di ProxyEndpoint determina la destinazione del proxy API e viene valutata dopo i criteri in PreFlow, Conditional Flows e PostFlow della richiesta ProxyEndpoint vengono elaborati.
Un ProxyEndpoint può definire la destinazione 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 una destinazione endpoint in base a una condizione.
- Route o target nulle, vale a dire che la richiesta non viene inoltrata a una destinazione. Invece, tutti 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 TargetEndpoint denominato configurazione. Ad esempio, la seguente <RouteRule> genera sempre una richiesta HTTP chiamata ad http://api.mycompany.com/myAPI:
<RouteRule name="default"> <URL>http://api.mycompany.com/myAPI</URL> </RouteRule>
Tuttavia, poiché non esiste un TargetEndpoint, è possibile aggiungere criteri solo ai flussi definiti dal ProxyEndpoint.
Destinazione singola
In una singola definizione di destinazione, ProxyEndpoint fa riferimento a una singola definizione di TargetEndpoint nome, come mostrato nella figura sopra riportata:
<RouteRule name="default"> <TargetEndpoint>default</TargetEndpoint> </RouteRule>
Tutte le richieste a questo proxy API sono indirizzate alla stessa definizione di TargetEndpoint. La <URL> nel tag TargetEndpoint determina la località del servizio di backend. nella figura sopra, il target L'URL è http://weather.yahooapis.com.
Target condizionali
Il tag <RouteRule> consente una richiesta viene indirizzata a una destinazione in base a una condizione. Puoi usare variabili di flusso, query parametri, intestazioni HTTP, contenuto 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 Stati Uniti e nel Regno Unito in un URL della richiesta. Puoi quindi instradare una richiesta a un endpoint di destinazione in base regione.
La seguente regola di route valuta un'intestazione HTTP in una richiesta. Se l'intestazione HTTP routeTo ha il valore TargetEndpoint1, quindi la richiesta viene inoltrato al 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 sono presenti più regole di route, creane una come "predefinita", ovvero senza alcuna condizione. Assicurati che la regola di route predefinita sia definita per ultima nell'elenco di route condizionali perché le regole vengono valutate dall'alto verso il basso nel ProxyEndpoint.
Vedi anche Percorsi condizionali e Riferimento alle condizioni.
Video: guarda un breve video per scoprire come indirizzare gli utenti verso un endpoint target utilizzando target condizionali.
Percorso Null
Una route null supporta scenari in cui non è necessario inoltrare il messaggio di richiesta a un TargetEndpoint. Ciò è utile quando ProxyEndpoint esegue tutte le elaborazioni necessarie, ad esempio usando JavaScript per chiamare un servizio esterno.
L'esempio seguente definisce una route nulla:
<RouteRule name="GoNowhere"/>