Compreender os trajetos

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

Uma rota determina o caminho de um pedido do ProxyEndpoint para o TargetEndpoint. A rota inclui o URL usado para aceder à API ProxyEndpoint e o URL do serviço de back-end definido pelo TargetEndpoint.

Veja este vídeo de introdução aos percursos, que descreve a relação entre o ProxyEndpoint e o TargetEndpoint.

Determinar o URL do ponto final do proxy de API

A imagem seguinte mostra um pedido a chegar ao ProxyEndpoint a partir de uma app e esse pedido a ser direcionado para o serviço de back-end:

Um pedido de cliente HTTP passa por um proxy de API no Apigee para o serviço HTTP e, em seguida, a resposta passa pelo proxy de API de volta para o cliente.

Depois de criar um proxy de API no Apigee, o URL predefinido que uma app usa para aceder ao proxy tem o seguinte formato:

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

Onde:

  • O nome de anfitrião é um domínio que adicionou ao DNS ou um endereço IP.
  • O caminho base e o caminho do recurso são definidos quando cria o proxy de API.

Quando o Apigee recebe um pedido, analisa o URL para direcionar o pedido para o ProxyEndpoint correto. Por exemplo, o seguinte URL é usado para aceder a um proxy de API:

http://example.com/v1/weather/forecastrss

Se examinar a definição de ProxyEndpoint para o proxy de API na figura acima, pode ver como este URL é analisado:

  1. A parte do URL referente ao domínio, http://example.com, corresponde a um nome do anfitrião definido num grupo de ambientes. O proxy foi implementado num ou mais ambientes nesse grupo de ambientes. Para mais informações, consulte o artigo Acerca dos ambientes e grupos de ambientes.
  2. A segunda parte do URL, /v1/weather, é determinada pelo elemento <BasePath> no elemento ProxyEndpoint. Definiu o caminho base quando criou o proxy. O caminho base tem de ser exclusivo do proxy de API para o ambiente, para que dois proxies de API no mesmo ambiente não tenham o mesmo caminho base.
  3. A terceira parte do URL, /forecastrss, é um recurso definido pelo proxy da API com o fluxo condicional correspondente definido pelo elemento <Flows>.

Vídeo: veja um breve vídeo para saber mais acerca dos pontos finais do proxy da API.

Determinar o URL do ponto final de destino

O elemento <RouteRule> numa definição de ProxyEndpoint determina o destino do proxy da API e é avaliado depois de todas as políticas no PreFlow, nos fluxos condicionais e no PostFlow do pedido ProxyEndpoint serem processadas.

Um ProxyEndpoint pode definir o alvo como:

  • Um URL direto para um serviço de back-end.
  • Uma única definição de TargetEndpoint.
  • Vários TargetEndpoints em que o proxy de API delega o pedido num ponto final de destino com base numa condição.
  • Trajeto ou destino nulo, o que significa que o pedido não é encaminhado para um destino. Em alternativa, todo o processamento do pedido e a geração da resposta ocorrem no Apigee.

Vídeo: veja um breve vídeo para saber mais sobre os pontos finais de destino.

URL direto

Um ProxyEndpoint pode invocar diretamente um serviço de back-end, ignorando qualquer configuração de TargetEndpoint com nome. Por exemplo, o seguinte <RouteRule> faz sempre uma chamada HTTP para http://example.com/myAPI:

<RouteRule name="default">
  <URL>http://example.com/myAPI</URL>
</RouteRule>

No entanto, como não existe nenhum TargetEndpoint, só pode adicionar políticas aos fluxos definidos pelo ProxyEndpoint.

Segmentação única

Numa única definição de destino, o ProxyEndpoint faz referência a uma única definição de TargetEndpoint pelo nome, conforme mostrado na figura acima:

<RouteRule name="default">
  <TargetEndpoint>default</TargetEndpoint>
</RouteRule>

Todos os pedidos a este proxy de API são direcionados para a mesma definição de TargetEndpoint. A etiqueta <URL> no TargetEndpoint determina a localização do serviço de back-end. Na figura acima, o URL de destino é http://weather.yahooapis.com.

Alvos condicionais

A etiqueta <RouteRule> permite-lhe direcionar um pedido para um alvo com base numa condição. Pode usar variáveis de fluxo, parâmetros de consulta, cabeçalhos HTTP, conteúdo de mensagens ou informações contextuais, como a hora do dia e o local, para determinar o ponto final de destino. Por exemplo, pode incluir uma área geográfica, como US e UK, num URL de pedido. Em seguida, pode encaminhar um pedido para um ponto final de destino com base na região.

A seguinte regra de encaminhamento avalia um cabeçalho HTTP num pedido. Se o cabeçalho HTTP routeTo tiver o valor TargetEndpoint1, o pedido é encaminhado para o TargetEndpoint denominado TargetEndpoint1. Caso contrário, o pedido é encaminhado para TargetEndpoint2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <TargetEndpoint>TargetEndpoint2</TargetEndpoint>
</RouteRule>

Se tiver várias regras de trajeto, crie uma como predefinição, ou seja, como uma regra de trajeto sem condição. Certifique-se de que a regra de encaminhamento predefinida é definida por último na lista de encaminhamentos condicionais, porque as regras são avaliadas de cima para baixo no ProxyEndpoint.

Consulte também Rotas condicionais e Referência de condições.

Vídeo: veja um breve vídeo para saber como encaminhar para um ponto final de destino através de destinos condicionais.

Trajeto nulo

Uma rota nula suporta cenários em que a mensagem de pedido não precisa de ser encaminhada para um TargetEndpoint. Isto é útil quando o ProxyEndpoint realiza todo o processamento necessário, por exemplo, usando JavaScript para chamar um serviço externo.

O exemplo seguinte define um trajeto nulo:

<RouteRule name="GoNowhere"/>

Saiba mais