Você está vendo a documentação do Apigee Edge.
Acesse a
documentação da Apigee X. informações
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.
O Apigee Edge oferece muita flexibilidade para criar um comportamento sofisticado baseado 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 políticas de chamadas de serviço, adicionar um comportamento personalizado com o código JavaScript e até mesmo criar um proxy de API que não invoque um serviço de back-end.
Antipadrão
Usar chamadas de serviço 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.
Você pode definir uma rota nula em um proxy de API, como 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 uma chamada de serviço a um proxy sem destino para invocar um serviço externo, como 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 analíticas sobre o comportamento do serviço externo (como tempo de processamento ou taxas de erro), dificultando 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 do 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.