Stai visualizzando la documentazione di Apigee Edge.
Vai alla
documentazione di Apigee X. informazioni
Un proxy API è un'interfaccia gestita per i servizi di backend. Una configurazione proxy API di base è composta da un ProxyEndpoint (che definisce l'URL del proxy API) e un TargetEndpoint (che definisce l'URL del servizio di backend).
Apigee Edge offre molta flessibilità per la creazione di comportamenti sofisticati basati su questo modello. Ad esempio, puoi aggiungere criteri per controllare il modo in cui l'API elabora una richiesta client prima di inviarla al servizio di backend oppure puoi manipolare la risposta ricevuta dal servizio di backend prima di inoltrarla al client. Puoi richiamare altri servizi utilizzando i criteri relativi ai callout di servizio, aggiungere un comportamento personalizzato mediante l'aggiunta di codice JavaScript e persino creare un proxy API che non richiami un servizio di backend.
Antipattern
L'utilizzo dei callout di servizio per richiamare un servizio di backend in un proxy API senza route verso un endpoint di destinazione è tecnicamente fattibile, ma comporta la perdita dei dati di analisi relativi alle prestazioni del servizio esterno.
Un proxy API che non contiene route di destinazione può essere utile nei casi in cui non sia necessario inoltrare il messaggio di richiesta a TargetEndpoint. Invece, ProxyEndpoint esegue tutte le elaborazioni necessarie. Ad esempio, ProxyEndpoint potrebbe recuperare i dati da una ricerca nell'archivio chiave/valore del servizio API e restituire la risposta senza richiamare un servizio di backend.
Puoi definire una route null in un proxy API, come mostrato qui:
<RouteRule name="noroute"/>
Un proxy che utilizza una route nulla è un proxy "senza destinazione", perché non richiama un servizio di backend di destinazione.
È tecnicamente possibile aggiungere un callout di servizio a un proxy no target per richiamare un servizio esterno, come mostrato nell'esempio di seguito:
<!-- /antipatterns/examples/service-callout-no-target-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request>
<Step>
<Name>ServiceCallout-InvokeBackend</Name>
</Step>
</Request>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/no-target-proxy</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="noroute"/>
</ProxyEndpoint>
Tuttavia, il proxy non è in grado di fornire informazioni di analisi sul comportamento del servizio esterno (ad esempio i tempi di elaborazione o le percentuali di errori), rendendo difficile la valutazione delle prestazioni del servizio esterno.
Impatto
- Le informazioni di analisi sull'interazione con il servizio esterno ( codici di errore, tempo di risposta, rendimento target e così via) non sono disponibili
- Qualsiasi logica specifica richiesta prima o dopo la chiamata del callout di servizio è inclusa come parte della logica generale del proxy, rendendola più difficile da comprendere e riutilizzare.
Best practice
Se un proxy API interagisce con un solo servizio esterno, deve seguire il pattern di progettazione di base, in cui il servizio di backend è definito come l'endpoint di destinazione del proxy API. Un proxy senza regole di routing verso un endpoint di destinazione non deve richiamare un servizio di backend utilizzando il criterio ServiceCallout.
La seguente configurazione proxy implementa lo stesso comportamento dell'esempio precedente, ma segue le best practice:
<!-- /antipatterns/examples/service-callout-no-target-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<FaultRules/>
<PreFlow name="PreFlow">
<Request/>
<Response/>
</PreFlow>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<Flows/>
<HTTPProxyConnection>
<BasePath>/simple-proxy-with-route-to-backend</BasePath>
<Properties/>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
</ProxyEndpoint>
Utilizza i callout di servizio per supportare scenari di mashup, in cui vuoi richiamare servizi esterni prima o dopo aver richiamato l'endpoint di destinazione. I callout di servizio non sono destinati a sostituire le chiamate degli endpoint di destinazione.