Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione
Documentazione di Apigee X. Informazioni
In Apigee Edge, un router gestisce tutto il traffico API in entrata. Ciò significa che tutte le connessioni HTTP e HTTPS le richieste a un proxy API Edge vengono prima gestite da un router Edge. Di conseguenza, una richiesta proxy API deve essere indirizzato all'indirizzo IP e alla porta aperta del router.
Un host virtuale consente di ospitare più nomi di dominio su un singolo server o gruppo di server. Per Edge, i server corrispondono ai router perimetrali. Se definisci host virtuali su un router, puoi gestire le richieste a più domini.
Un host virtuale su Edge definisce un protocollo (HTTP o HTTPS), una porta del router e un alias host. L'alias host è in genere un nome di dominio DNS che viene mappato all'indirizzo IP di un router.
Ad esempio, la seguente immagine mostra un router con due definizioni di host virtuali:
In questo esempio sono presenti due definizioni di host virtuale. Uno gestisce le richieste HTTPS dominio domainName1, l'altro gestisce le richieste HTTP su domainName2.
Su una richiesta a un proxy API, il router confronta l'intestazione Host e il numero di porta dell'interfaccia una richiesta all'elenco di alias host definiti da tutti gli host virtuali per determinare l'host virtuale gestisce la richiesta.
Di seguito è riportata una configurazione di esempio per gli host virtuali:
Antipattern
Definizione di più host virtuali con lo stesso alias host e numero di porta nello stesso indirizzo o in uno stesso ambienti di un'organizzazione o tra organizzazioni porterà alla confusione al momento di routing delle richieste API e che potrebbero causare errori/comportamenti imprevisti.
Utilizziamo un esempio per spiegare le implicazioni derivanti dall'avere più host virtuali con lo stesso alias host.
Considera che esistano due host virtuali sandbox and secure
definiti
con lo stesso alias host, ad es. api.company.abc.com
in un ambiente:
Con la configurazione di cui sopra, possono esservi due scenari, come descritto nelle sezioni seguenti.
Scenario 1 : un proxy API è configurato per accettare richieste solo a uno sandbox host
<ProxyEndpoint name="default"> ... <HTTPProxyConnection> <BasePath>/demo</BasePath> <VirtualHost>sandbox</VirtualHost> </HTTPProxyConnection> ... </ProxyEndpoint>
In questo scenario, quando le applicazioni client effettuano le chiamate a un proxy API specifico utilizzando
alias host api.company.abc.com
, riceveranno a intermittenza errori 404 con il messaggio:
Unable to identify proxy for host: secure
Questo perché il router invia le richieste sia a sandbox
sia a secure
degli host virtuali. Quando le richieste vengono instradate all'host virtuale sandbox
, le applicazioni client
otterrà una risposta positiva. Tuttavia, quando le richieste vengono instradate all'host virtuale secure
,
le applicazioni client riceveranno l'errore 404 perché il proxy API non è configurato per accettare richieste su
Host virtuale secure
.
Scenario 2 : un proxy API è configurato per accettare richieste sia alla sandbox degli host virtuali sia alla
<ProxyEndpoint name="default"> ... <HTTPProxyConnection> <BasePath>/demo</BasePath> <VirtualHost>sandbox</VirtualHost> <VirtualHost>secure</VirtualHost> </HTTPProxyConnection> ... </ProxyEndpoint>
In questo scenario, quando le applicazioni client effettuano le chiamate a un proxy API specifico utilizzando
alias host api.company.abc.com
, riceveranno una risposta valida basata sulla logica del proxy.
Tuttavia, questo fa sì che in Analytics vengano archiviati dati errati mentre le richieste API vengono indirizzate alle su entrambi gli host virtuali, mentre le richieste effettive erano destinate a essere inviate a un solo host virtuale.
Ciò può anche influire sulle informazioni di logging e su eventuali altri dati basati sugli host virtuali.
Impatto
- Errori 404, poiché le richieste API potrebbero essere instradate a un host virtuale a cui il proxy API potrebbe non essere configurate per accettare le richieste.
- Dati di Analytics errati poiché le richieste API vengono instradate a tutti gli host virtuali con lo stesso alias host mentre le richieste sono state effettuate solo per un host virtuale specifico.
Best practice
- Non definire più host virtuali con lo stesso alias host e numero di porta nello stesso ambiente. o da ambienti diversi di un'organizzazione.
Se è necessario definire più host virtuali, utilizza alias host diversi in ciascuno dagli host virtuali, come illustrato di seguito: