Antipatrón: usar la política de llamada de servicio para invocar un servicio de backend en un proxy de API sin destino

Estás consultando la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.

Un proxy de API es una fachada gestionada para los servicios de backend. Una configuración básica de proxy de API consta de un elemento ProxyEndpoint (que define la URL del proxy de API) y un elemento TargetEndpoint (que define la URL del servicio de backend).

Apigee ofrece mucha flexibilidad para crear comportamientos sofisticados a partir de este patrón. Por ejemplo, puedes añadir políticas para controlar la forma en que la API procesa una solicitud de cliente antes de enviarla al servicio de backend o manipular la respuesta recibida del servicio de backend antes de reenviarla al cliente. Puede invocar otros servicios mediante políticas de llamada de servicio, añadir un comportamiento personalizado añadiendo código JavaScript e incluso crear un proxy de API que no invoque un servicio de backend.

Antipatrón

Aunque técnicamente es posible usar llamadas de servicio para invocar un servicio de backend en un proxy de API sin rutas a un endpoint de destino, se pierden los datos analíticos sobre el rendimiento del servicio externo.

Un proxy de API que no contiene rutas de destino puede ser útil en los casos en los que no necesites reenviar el mensaje de solicitud a TargetEndpoint. En su lugar, ProxyEndpoint realiza todo el procesamiento necesario. Por ejemplo, ProxyEndpoint podría recuperar datos de una búsqueda en el almacén de pares clave-valor del servicio de API y devolver la respuesta sin invocar un servicio de backend.

Puedes definir una ruta nula en un proxy de API, como se muestra a continuación: 

<RouteRule name="noroute"/>

Un proxy que usa una ruta nula es un proxy "sin destino", ya que no invoca un servicio de backend de destino.

Técnicamente, es posible añadir una llamada 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 error), lo que dificulta la evaluación de su rendimiento.

Impacto

  • No se puede acceder a la información analítica sobre la interacción con el servicio externo ( códigos de error, tiempo de respuesta, rendimiento objetivo, etc.).
  • Cualquier lógica específica que se requiera antes o después de invocar la llamada de servicio se incluye como parte de la lógica general del proxy, lo que dificulta su comprensión y reutilización.

Práctica recomendada

Si un proxy de API interactúa solo con un servicio externo, debe seguir el patrón de diseño básico, en el que el servicio de backend se define como el endpoint de destino del proxy de API. Un proxy sin reglas de enrutamiento a un endpoint 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 llamadas de servicio para admitir escenarios de mashup en los que quieras invocar servicios externos antes o después de invocar el endpoint de destino. Las llamadas de servicio no están pensadas para sustituir la invocación de endpoints de destino.

Más información