Antipadrão: usar a política Service Callout para invocar um serviço de back-end em um proxy da API que não seja de destino

Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.

Um proxy de API é uma fachada gerenciada para serviços de back-end. Uma configuração básica de proxy de API consiste em um ProxyEndpoint, que define o URL do proxy da API, e um TargetEndpoint, que define o URL do serviço de back-end.

A Apigee oferece muita flexibilidade para criar um comportamento sofisticado nesse padrão. Por exemplo, é possível adicionar políticas para controlar a maneira como a API processa uma solicitação do cliente antes de enviá-la ao serviço de back-end, ou manipular a resposta recebida do serviço de back-end antes de encaminhá-la para o cliente. É possível invocar outros serviços usando as políticas Service Callout, adicionar um comportamento personalizado com a inclusão do código JavaScript e até mesmo criar um proxy de API que não invoca um serviço de back-end.

Antipadrão

O uso de Service Callouts para invocar um serviço de back-end em um proxy de API sem rotas para um endpoint de destino é tecnicamente viável, mas resulta na perda de dados de análise sobre o desempenho do serviço externo.

Um proxy de API que não contém rotas de destino pode ser útil quando você não precisa encaminhar a mensagem de solicitação para o TargetEndpoint. Em vez disso, o ProxyEndpoint executa todo o processamento necessário. Por exemplo, o ProxyEndpoint pode recuperar dados de uma pesquisa no armazenamento de chave/valor do serviço de API e retornar a resposta sem invocar um serviço de back-end.

Defina uma rota nula em um 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 service callout a um proxy de 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 análise sobre o comportamento do serviço externo, como tempo de processamento ou taxas de erro, por exemplo. Isso dificulta a avaliação do desempenho do serviço externo.

Impacto

  • As informações de análise sobre a interação com o serviço externo, como códigos de erro, tempo de resposta, desempenho de destino, entre outros, não estão disponíveis.
  • Qualquer lógica específica necessária antes ou depois de invocar a Service Callout é incluída como parte da lógica geral do proxy, dificultando a compreensão e a reutilização.

Prática recomendada

Se um proxy de API interagir com apenas um serviço externo, o proxy deverá seguir o padrão de projeto básico, em que o serviço de back-end é definido como o endpoint de destino do proxy de API. Um proxy sem regras de roteamento para um endpoint de destino não pode invocar um serviço de back-end usando a política ServiceCallout.

A configuração de proxy a seguir 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 Service Callouts para aceitar cenários de mashup, em que você quer invocar serviços externos antes ou depois de invocar o endpoint de destino. As Service Callouts não têm a finalidade de substituir a invocação do endpoint de destino.

Leitura adicional