Antipattern: use a política de chamadas de serviço para invocar um serviço de back-end num proxy de API sem destino

Está a ver a documentação do Apigee e do Apigee Hybrid.
Veja a documentação do Apigee Edge.

Um proxy de API é uma fachada gerida para serviços de back-end. Uma configuração básica do proxy de API consiste num ProxyEndpoint (que define o URL do proxy de API) e num TargetEndpoint (que define o URL do serviço de back-end).

O Apigee oferece muita flexibilidade para criar um comportamento sofisticado com base neste padrão. Por exemplo, pode adicionar políticas para controlar a forma como a API processa um pedido do cliente antes de o enviar ao serviço de back-end ou manipular a resposta recebida do serviço de back-end antes de a encaminhar para o cliente. Pode invocar outros serviços através de políticas de chamadas de serviços, adicionar um comportamento personalizado adicionando código JavaScript, e até criar um proxy de API que não invoque um serviço de back-end.

Antipattern

A utilização de chamadas de serviço para invocar um serviço de back-end num proxy de API sem rotas para um ponto final de destino é tecnicamente viável, mas resulta na perda de dados de estatísticas sobre o desempenho do serviço externo.

Um proxy de API que não contenha rotas de destino pode ser útil nos casos em que não precisa de encaminhar a mensagem de pedido para o TargetEndpoint. Em alternativa, o ProxyEndpoint realiza todo o processamento necessário. Por exemplo, o ProxyEndpoint pode obter dados de uma pesquisa no arquivo de chave/valor do serviço de API e devolver a resposta sem invocar um serviço de back-end.

Pode definir uma rota nula num proxy de API, conforme mostrado aqui: 

<RouteRule name="noroute"/>

Um proxy que usa uma rota nula é um proxy "sem destino" porque não invoca um serviço de back-end de destino.

Tecnicamente, é possível adicionar um texto destacado de serviço a um proxy sem destino para invocar um serviço externo, conforme mostrado no exemplo abaixo: 

<!-- /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>

No entanto, o proxy não pode fornecer informações de estatísticas sobre o comportamento do serviço externo (como o tempo de processamento ou as taxas de erro), o que dificulta a avaliação do desempenho do serviço externo.

Impacto

  • As informações de estatísticas sobre a interação com o serviço externo ( códigos de erro, tempo de resposta, desempenho do destino, etc.) estão indisponíveis
  • Qualquer lógica específica necessária antes ou depois de invocar o callout do serviço é incluída como parte da lógica geral do proxy, o que dificulta a compreensão e a reutilização.

Prática recomendada

Se um proxy de API interagir apenas com um único serviço externo, o proxy deve seguir o padrão de design básico, em que o serviço de back-end é definido como o ponto final de destino do proxy de API. Um proxy sem regras de encaminhamento para um ponto final de destino não deve invocar um serviço de back-end através da política ServiceCallout.

A seguinte configuração de proxy implementa o mesmo comportamento que o exemplo acima, mas segue as práticas 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>

Use os destaques de serviços para suportar cenários de mashup, em que quer invocar serviços externos antes ou depois de invocar o ponto final de destino. Os pedidos de serviços não se destinam a substituir a invocação do ponto final de destino.

Leitura complementar