Estás consultando la documentación de Apigee Edge.
Consulta la
documentación de Apigee X. Información
Un proxy de API es una fachada administrada para servicios de backend. Una configuración básica de proxy de API consta de un ProxyEndpoint (que define la URL del proxy de API) y un TargetEndpoint (que define la URL del servicio de backend).
Apigee Edge ofrece mucha flexibilidad para compilar comportamientos sofisticados a partir de este patrón. Por ejemplo, puedes agregar políticas para controlar la forma en que la API procesa una solicitud de un cliente antes de enviarla al servicio de backend o para manipular la respuesta que se recibe del servicio de backend antes de reenviarla al cliente. Puedes invocar otros servicios con las políticas de texto destacado del servicio, agregar un comportamiento personalizado agregando código JavaScript o incluso crear un proxy de API que no invoque un servicio de backend.
Antipatrón
El uso de solicitudes de oferta de servicio para invocar un servicio de backend en un proxy de API sin rutas a un extremo de destino es técnicamente factible, pero genera la pérdida de datos de estadísticas sobre el rendimiento del servicio externo.
Un proxy de API que no contiene rutas de destino puede ser útil en casos en los que no necesites reenviar el mensaje de solicitud al TargetEndpoint. En su lugar, el ProxyEndpoint realiza todo el procesamiento necesario. Por ejemplo, el ProxyEndpoint puede recuperar datos de una búsqueda en el almacén de clave-valor del servicio de la API y mostrar la respuesta sin invocar un servicio de backend.
Puedes definir una ruta nula en un proxy de API, como se muestra aquí:
<RouteRule name="noroute"/>
Un proxy que usa una ruta nula es un proxy "sin destino" porque no invoca un servicio de backend de destino.
Técnicamente, es posible agregar un texto destacado de servicio a un proxy sin destino para invocar un servicio externo, como se muestra en el siguiente ejemplo:
<!-- /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>
Sin embargo, el proxy no puede proporcionar información analítica sobre el comportamiento del servicio externo (como el tiempo de procesamiento o las tasas de errores), lo que dificulta la evaluación del rendimiento del servicio externo.
Impacto
- La información estadística sobre la interacción con el servicio externo (códigos de error, tiempo de respuesta, rendimiento objetivo y demás) no está disponible.
- Toda lógica específica requerida antes o después de invocar el texto destacado del servicio se incluye como parte de la lógica general del proxy, lo que dificulta la comprensión y la reutilización.
Práctica recomendada
Si un proxy de API interactúa con un solo servicio externo, el proxy debe seguir el patrón de diseño básico, en el que el servicio de backend se define como el extremo de destino del proxy de API. Un proxy sin reglas de enrutamiento para un extremo de destino no debe invocar un servicio de backend mediante la política ServiceCallout.
La siguiente configuración de proxy implementa el mismo comportamiento que el ejemplo anterior, pero sigue las prácticas recomendadas:
<!-- /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>
Usa textos destacados del servicio para admitir situaciones de mashup, en las que quieres invocar servicios externos antes o después de invocar el extremo de destino. Los textos destacados del servicio no deben reemplazar la invocación del extremo de destino.