Antipatrón: Usa la política de texto destacado del servicio para invocar un servicio de backend en un proxy de API sin destino

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

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 ofrece mucha flexibilidad para la compilación de un comportamiento sofisticado, además 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 mediante políticas Service Callout, agregar comportamiento personalizado si agregas código de JavaScript y hasta crear un proxy de API que no invoque un servicio de backend.

Antipatrón

Usar políticas Service Callout para invocar un servicio de backend en un proxy de API sin rutas a un extremo de destino es técnicamente posible, 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", ya que no invoca un servicio de backend de destino.

Técnicamente, es posible agregar una política Service Callout a un proxy de 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 estadística sobre el comportamiento del servicio externo (como el tiempo de procesamiento o las tasas de error), 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 la política Service Callout 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.

Mediante la siguiente configuración de proxy, se implementa el mismo comportamiento que en el ejemplo anterior, pero se siguen 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 políticas Service Callout para admitir situaciones de mashup, en las que quieres invocar servicios externos antes o después de invocar el extremo de destino. Las políticas Service Callouts no deben reemplazar la invocación del extremo de destino.

Lecturas adicionales