Flow de uma API

A arquitetura para exposição de APIs amplamente adotada no mercado prevê a separação de responsabilidades, onde a presença de um gateway de APIs como elemento intermediário entre os clientes e o backend é fundamental.

Por padrão, todos os dados de uma requisição (request) são passados sem alterações para o backend, apontado pelo roteamento do gateway. O mesmo acontece com a resposta (response) enviada pelo backend. Por padrão, todos os dados da resposta são passados sem alterações para o cliente que originou a requisição.

Contudo, há diversas situações onde é necessário modificar os dados da requisição antes de enviá-la ao backend, ou alterar o response padrão que será devolvido ao cliente. Por exemplo:

  • Adicionar informações à requisição antes de encaminha-la ao backend (enriquecimento de mensagens);
  • Remover ou mascarar informações sensíveis que não devem ser armazenadas em logs;
  • Tomar decisões de rotas com base no conteúdo das mensagens;
  • Compor mais de uma chamada a serviços internos em uma mesma requisição externa.

A definição de uma API inclui a configuração dos fluxos de entrada e saída das mensagens. No caminho desses fluxos podem ser adicionados interceptadores (executam lógicas e estabelecem comportamentos) em pontos específicos, que serão executados em uma ordem bem definida.

A execução dos interceptadores segue uma hierarquia em árvore, respeitando a ordem na qual foram configurados.

Abaixo, um cenário onde interceptadores são adicionados nos fluxos de entrada e saída das mensagens:

Na configuração do fluxo, de acordo com a imagem acima, podem ser definidos:

  1. O escopo de execução do fluxo, sendo:
  • resources: exibe todos os recursos da API. Quando selecionado ALL, o fluxo será refletido para todas as operações;
  • operations: exibe todas as operações para o recurso selecionado. Segue o mesmo conceito dos recursos, se for selecionado ALL o mesmo será refletido em todas as operações;

 

  1. O conjunto de interceptors, sendo divididos em: Traffic, Security, Mediation, Tracing, Transformation, Custom .
  2. O ponto de execução da requisição realizada do cliente para o servidor. A ordem dos interceptors da esquerda para direita definem como será o processamento. Todos os interceptors são válidos para este ponto de execução;
  3. O ponto de execução da resposta retornada do servidor para o cliente, mediante algum processamento dos interceptors. A ordem dos interceptors da direita para esquerda. Alguns interceptors não fazem parte deste ponto de execução como: Client ID validation, Access Token Validation e OAuth.
  4. Os Destinations da API são inseridos na tela de Flow. O destination pode ser inserido no fluxo ALL, onde todas as chamadas daquela API serão redirecionadas para o mesmo destination, ou ainda, inserir destinations específicos para recursos e operações.
  5. Na mesma tela, ainda pode ser definido um timeout específico para cada operação, recurso ou para a revisão. O timeout determina o tempo limite de espera de consumo de um determinado recurso. Quando o tempo de uma requisição exceder o valor do timeout configurado, a requisição será abortada e uma exceção será lançada pelo sistema com o status 502.
  6. O campo timeout pode ser definido diretamente, um valor em segundos, ou através de uma variável de environment.
  7. Assim como a hierarquia de destinations, o timeout segue o mesmo conceito: do mais genérico para o mais específico. Ex: Um timeout definido em All será replicado para todos os recursos e operações, ao menos que seja definido um timeout diferente em um componente mais específico.

Fluxo

Podemos criar vários fluxos para uma chamada na API. O interceptors podem ser definidos e executados no Resources e Operations.

Os fluxos seguem um modelo de hierarquia, ou seja, os inteceptors do pai serão herdados pelos seus filhos, mas as modifições nos filhos não serão refletidas no pai, conforme mostra as figuras acima.

Os interceptors herdados de seu pai estarão em cinza escuro, enquanto os próprios estarão coloridos:

Quebra de Fluxo

Uma quebra de fluxo é caracterizada quando houver alteração na ordem dos interceptors herdados de um fluxo pai, haverá uma quebra de fluxo, onde todas as alterações feitas nos interceptors do fluxo pai não serão repassadas para seus filhos.

O que causa quebra de fluxo

  • Mudança da ordem dos interceptors herdados do pai;
  • Mudança da ordem dos interceptors do filho, na frente dos herdados do pai;
  • Mudança da ordem dos interceptors do filho, no meio dos herdados do pai;
  • Adição de novo interceptor, na frente dos interceptors herdados do pai;
  • Adição de novo interceptor, no meio dos interceptors herdados do pai.

O que não causa quebra de fluxo

  • Mudança da ordem dos interceptor do filho, depois do intercetors do pai;
  • Adição de novo interceptor, depois dos interceptors herdados do pai;
  • Alteração dos valores dos intercetors do pai.

Obs: Os valores alterados no filho serão transmitidos para seus filhos herdeiros, porém se houver uma alteração no valor do pai, esta não será transmitida para o filhos nem para os filhos herdeiros.

A imagem a seguir representa um fluxo filho normal, onde os interceptors em cinza são herdados e foi adicionado um interceptor de Log no request, obedecendo a ordem dos interceptors.

Em seguida temos um exemplo de uma Quebra de Fluxo. A ordem dos interceptors foi alterada, foi adicionado um interceptor de Client ID Validation antes do primeiro interceptor herdado do fluxo pai (Rate Limit), e portanto qualquer alteração feita no fluxo pai não será refletida no fluxo em questão.

É possível reverter a quebra de fluxo clicando no botão de Restore localizado ao lado do combo de seleção de Operations.

Tem mais dúvidas? Envie uma solicitação

Comentários

Powered by Zendesk