Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Visualizza
Documentazione di Apigee Edge.
Un proxy API è un'interfaccia gestita per i servizi di backend. Una configurazione di base del proxy API è composta da un ProxyEndpoint (che definisce l'URL del proxy API) e un TargetEndpoint (che definisce l'URL del servizio di backend).
Apigee offre molta flessibilità per creare comportamenti sofisticati in base a questo pattern. Ad esempio, puoi aggiungere criteri per controllare il modo in cui l'API elabora una richiesta del client prima dell'invio al servizio di backend o manipolare la risposta ricevuta dal servizio di backend inoltrandolo al client. Puoi richiamare altri servizi utilizzando norme sui callout dei servizi, aggiungi un comportamento personalizzato aggiungendo codice JavaScript, e persino creare un proxy API che non richiama un servizio di backend.
Antipattern
Utilizzo dei callout di servizio per richiamare un servizio di backend in un proxy API senza route a un endpoint di destinazione è tecnicamente fattibile, ma comporta la perdita dei dati di analisi sul rendimento esterno.
Un proxy API che non contiene route di destinazione può essere utile nei casi in cui non è necessario inoltrare il messaggio di richiesta al TargetEndpoint. Invece, il ProxyEndpoint esegue tutte le operazioni necessarie e l'elaborazione dei dati. Ad esempio, ProxyEndpoint potrebbe recuperare i dati da una ricerca nel archiviano e restituiscono 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 è "nessun target" perché non richiama un servizio di backend di destinazione.
È tecnicamente possibile aggiungere il callout di un servizio a un proxy non di destinazione per richiamare un servizio esterno, come illustrato nell'esempio riportato 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 può fornire informazioni di analisi sul comportamento del servizio esterno (ad esempio tempo di elaborazione o tassi di errore), rendendo difficile la valutazione delle prestazioni del servizio esterno.
Impatto
- Informazioni di Analytics sull'interazione con il servizio esterno ( codici di errore, tempo di risposta, rendimento target e così via) non è disponibile
- Qualsiasi logica specifica necessaria prima o dopo la chiamata del callout del servizio è inclusa come parte della logica generale del proxy, rendendolo più difficile da capire e riutilizzare.
Best practice
Se un proxy API interagisce con un solo servizio esterno, il proxy deve seguire le di progettazione, in cui il servizio di backend è definito come l'endpoint di destinazione del proxy API. Un proxy senza regole di routing a 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 meglio pratiche:
<!-- /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 l'endpoint di destinazione invocazione.
Per approfondire
- Informazioni su API e proxy API
- Come configurare le regole di route
- Percorsi inattivi
- Norme relative ai callout di servizio