Como utilizar heranças no fluxo das APIs

A utilização de heranças nos fluxos das APIs é muito benéfica para evitar a repetição de configurações, utilizando-a é possível diminuir a complexidade e consequentemente facilitar as futuras manutenções. Veja nesse artigo como utilizar heranças no fluxo das suas APIs.

 

Para todo o artigo, considere a API 'Heranças' com base path /herancas e os seguintes recursos e operações:

 

 

Utilizando herança no Target Destination

Imagem acima mostra o local onde o valor do Target Destination é inserido. 

O Target Destination é o back-end que o API Gateway fará a requisição após a execução do fluxo de request.

 

Caso o Target Destination seja inserido somente no Resources (All) Operations (All), o gateway concatenará com o recurso chamado e caso ele esteja cadastrado na API o fluxo mais específico será chamado. Exemplo com a API Heranças:

  • Target Destination no Resources (All) Operations (All) possui o valor: http://supermock.demo.sensedia.com/
  • Todos os outros Target Destinations estão em branco nos outros fluxos.

Nesse contexto, as chamadas GET, POST, PUT, DELETE para <...>/herancas/pratos e <...>/herancas/categorias irão seguir o fluxo mais específico.

Chamada Fluxo utilizado na chamada
GET /herancas/pratos Resources (Pratos) Operations (GET)
POST /herancas/pratos Resources (Pratos) Operations (POST)
PUT /herancas/pratos Resources (Pratos) Operations (PUT)
DELETE /herancas/pratos Resources (Pratos) Operations (DELETE)
GET /herancas/categorias Resources (Categorias) Operations (GET)
POST /herancas/categorias Resources (Categorias) Operations (POST)
PUT /herancas/categorias Resources (Categorias) Operations (PUT)
DELETE /herancas/categorias Resources (Categorias) Operations (DELETE)
GET /herancas/carros Resources (All) Operations (All)
GET /herancas/motos Resources (All) Operations (All)

O Target Destination resultante das chamadas seria http://supermock.demo.sensedia.com/ + recurso-chamado

Exemplos:

GET /herancas/categorias --> http://supermock.demo.sensedia.com/categorias

GET /herancas/ (assim mesmo, sem recurso na chamada) --> http://supermock.demo.sensedia.com/ 

Chamadas de recursos não existentes na API

É importante ressaltar que todas as chamadas serão enviadas para o back-end, até mesmo dos recursos não cadastrados, haja vista que as chamadas de recursos não cadastrados utilizariam o Target Destination de Resources (All) Operations (All).

 

Considerando o exemplo anterior, onde o Target Destination de Resources (All) Operations (All) é http://supermock.demo.sensedia.com/ as chamadas de recursos não cadastrados resultariam em um Target Destination de http://supermock.demo.sensedia.com/ + 'recurso-inexistente-chamado'

Chamada Fluxo utilizado na chamada Target Destination
GET /herancas/viagens Resources (All) Operations (All) https://supermock.demo.sensedia.com/viagens
GET /herancas/planos Resources (All) Operations (All) https://supermock.demo.sensedia.com/planos

 

Como alternativa, é possível colocar Target Destinations específicos para Resource (Pratos) Operations (All) e Resource (Categorias) Operations (All) e omitir o Target Destination no Resources (All) Operations (All). Assim quando um recurso não cadastrado for chamado ainda será utilizado o fluxo de Resources (All), porém como não existe um Target Destination configurado a requisição para o back-end não será feita.

 

Utilizando herança nos Interceptors

Interceptors podem customizar os fluxos das suas APIs, alterando os Target Destinations, adicionando segurança e criptografia na chamadas, limitando quantidade de chamadas, etc. Porém caso a API possua muitos recursos a manutenção dos Interceptors pode resultar em um trabalho muito repetitivo. Para isso não acontecer é necessário a utilização de herança nos Interceptors.

Se os interceptors forem adicionados no Resources (All) Operations (All), automaticamente todos os fluxos mais específicos herdaram esses interceptors. Abaixo adicionamos na Resources (All) Operations (All) da API Herança três interceptors: Log e Custom Javascript no fluxo da request e Log no fluxo da response.

 

Imagem acima mostra Interceptors adicionados no Resources (All) Operations (All)

 

Os interceptors herdados serão indicados pela cor cinza. No exemplo da imagem abaixo, é possível observar os  3 interceptors de Resources (Pratos) Operations (POST) que foram herdados de Resources (All) Operations (All). Os outros fluxos também possuem essa herança, a imagem abaixo serve  apenas de exemplificação de um deles:

 

Imagem acima mostra um fluxo específico que herdou interceptors de Resources (All) Operations (All)

 

Também é possível herdar Interceptors de um Resources (nome-recurso) Operations (All) como veremos em seguida. Assim é possível especificar interceptors para um recurso sem necessariamente adicionar em cada fluxo específico dele.

A Imagem acima mostra que o Resources (Categorias) Operations (All) herdou três Intercptors de Resources (All) Operations (All), indicados na cor cinza. Adicionando o interceptor 'EventDriven' fará que todas as operations desse recurso possua esse interceptor.

 

Cuidado para não quebrar o fluxo

No exemplo anterior poderíamos ter adicionado o Interceptor 'EventDriven' no meio do interceptor de Log e Interceptor Java Script. Isso não deve ser feito pois 'quebra o fluxo', isto é, a herança não será mais aplicada e para corrigir isso é necessário restaurar todo o fluxo clicando no botão de reset:

Tome cuidado! Essa ação de reset não é reversível, faça ciente de que os Interceptors serão removidos para voltar ao estado padrão em que a herança é válida.

 

O que causa quebra de fluxo

Em essência, qualquer mudança de ordem nos Interceptors herdados gerará a quebra. Para evitar essa quebra, basta imaginar o fluxo como um 'vetor' e caso você esteja mudando o índice dos interceptors herdados, de fato o fluxo será quebrado.

Na imagem acima caso o EventDriven estivesse na posição '0' ou '1' o fluxo seria quebrado ou até mesmo se o Header (nº 4 na imagem) estivesse antes do Interceptor de Log no fluxo de response. Isso pois o Log herdado estaria na posição 4 (alteração do índice).

 

Mudança no código de Interceptors Javascript

Caso seja feita alguma alteração no código em um Interceptor de Javascript que foi herdado, ele ganhará o status CHANGED, e não refletirá as eventuais alterações que o fluxo 'pai causador da herança'. Porém os fluxos que herdarem desse fluxo com o Interceptor CHANGED refletirão as alterações do Interceptor CHANGED.

Caso deseje retirar o CHANGED do Interceptor para voltar ao comportamento padrão é necessário fazer o reset do fluxo, porém, como mencionado anteriormente essa ação requer cuidado pois não há como revertê-la.

Conclusão

Trabalhar com heranças pode ser muito útil, porém exige o entendimento de todo o funcionamento para evitar futuros problemas. Veja na seção dedicada no manual da plataforma mais informações a respeito do fluxo.

 

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

Comentários

Desenvolvido por Zendesk