Como prometido no post anterior, onde usamos o AWS API Gateway (https://skalena.net/blog/implementando-apis-do-openbanking-com-aws-api-gateway/) para expor nossos Backends de implementações das APIs de Open Banking de acordo com a Febraban: https://febraban.github.io/Open-Banking-/ . Nesta oportunidade vamos mostrar o Azure API Manager:
Na página de produto https://azure.microsoft.com/pt-br/services/api-management/ , você pode encontrar mais detalhes da solução, assim como a capacidade de começar a usar a solução até mesma de forma gratuita.
Você pode solicitar créditos de uso da Azure, que podem lhe ser úteis no uso de vários componentes de nuvem e como serviços providos pela Microsoft.
Acessando o Portal de Gerenciamento de APIs
Uma vez que você estiver conectado no seu ambiente com sua conta Azure, você poderá buscar por “API Manager”, assim como na tela abaixo:
Console de Serviços da Azure
O Processo de criação é extremamente simples, veja a imagem a seguir:
Uma vez você passe pelo processo anterior de criação do serviço, você será direcionado para a página do recurso API Management:
Relembrando o papel do API Gateway e do API Manager
Estes dois termos algumas vezes podem gerar algumas confusões, pois algumas pessoas pensam que são a mesma coisa, e não são! Vale aqui uma breve explicação, do alcance de cada uma das soluções:
API Gateway: É um componente que faz o papel de centralizar os acessos aos Backends:
Imagem do papel do API Gateway:
O API Gateway é também conhecido como um pattern(padrão), do popular catálogo de Microserviços do site Microservices.io( https://microservices.io/patterns/apigateway.html). Uma outra grande vantagem da centralização do API Gateway é o reaproveitamento de serviços comuns como: Segurança, Cache, controle de vazão, BFF (Backend for Front-end), etc, de forma que o Backend não precise se preocupar com estes aspectos e delegue esta tarefa para o Gateway central:
A diferença de serviços comuns em cada Backend e todos centralizados pelo API Gateway
Imagine dar manutenção em Microserviços/backends escritos em tecnologias diferentes, com diversas bibliotecas, em estágios de pipelines e entregas diferentes, imagine o trabalho e dor de cabeça que isto trazia para as organizações.
API Manager : Espara-se desta categoria de produtos que alguns componentes além do API Gateway sejam entregues, como por exemplo: Serviços de informações analíticas, Portal de Desenvolvedor, componentes e/ou recursos de bilhetagem e medição de consumo das APIs, um provedor de chaves e autorização dos serviços etc.
Pode-se dizer que o Azure API Manager, está mais para a categoria de um API Manager, do que apenas um API Gateway, visto alguns recursos que veremos agora. (ps- Em breve iremos falar de um projeto da Skalena que visa entregar um API Gateway de altíssima performance para o mercado, fique atento as nossas novidades.)
Sempre começando pelo API:First
Como uma de nossas práticas sempre usadas em nossos projetos, está sempre tentar começar as APIs pelos seus contratos, ou seja, pelo Open API Spec ou Swagger. No caso da API da Febraban, nós vamos utilizar o seguinte contrato: https://github.com/skalena/openbankingBR/blob/master/febraban/metrics.yaml
Para importar este arquivo, podemos usar a opção Rawfile do GitHub: https://raw.githubusercontent.com/skalena/openbankingBR/master/febraban/metrics.yaml
Em nossa interface de gestão, vamos selecionar a opção APIs, como é mostrado na imagem abaixo:
Selecione a opção Open API de acordo a imagem apresentada a seguir, informe os valores de acordo:
Informe o Swagger e um nóme válido, assim como display name (exibição) e API URL Sufix, que irá ser importante para o endereço da sua API
Com o passo anterior, os recursos da sua Open API já estarão disponíveis para que você possa configurá-los. Como nossa API em questão é simples, você terá apenas um único resource do tipo GET com o nome metrics, de acordo com a seguinte imagem:
Configuração do Resource HTTP
Observe que a interface acima, lembra muito do AWS API Gateway, então, a configuração será tão intuitiva quanto. A esquerda temos a seção Frontend, que trata das configuração do recurso. Ao meio, na extremidade superior temos a seção Inbound processing que por sua vez, se destina a configurações da chegada da requisição, antes que esta seja enviada o Backend, que por sinal é a seção a nossa direita, que trata exatamente da capacidade de informar qual o endereço do Backend(microserviço, serviço, serverless etc) que irá processar a requisição. Por último, temos o Outbound processing que é a seção que trata quando o backend retornou a operação e possívelmente com dados de retorno para o originador da requisição.
Para o Inbound processing, nós podemos adicionar inúmeras capacidades extra, como as apresentadas na image a seguir:
Policies que você pode adicionar na chegada da requisição
Dependendo do que você queira fazer, você já tem prontas inúmeras políticas que lhe permitem proteger e melhorar a entrega das suas APIs, entre as atividades que você pode fazer, podemos citar:
Filtrar por IP que está chamando a API
Limitar o número de chamadas a esta API
Criar uma resposta Mock (exemplo/rascunho) apenas
Adicionar parametros a URL de destino do Backend
Adicionar cabeçalhos HTTP, por exemplo Basic Authorization, X-Qualquer-Header etc.
Validar tokens JWT
Permitir CORS
Adicionar respostas a um Cache
Políticas customizadas
Etc
Veja que em nosso exemplo, vamos adicionar uma Policy de Rate Limiting, dizendo que independente do IP, este só poderá realizar o máximo de 10 chamadas:
Definição de Rate-Limiting
Lembrando, que podemos adicionar ainda nossas políticas customizadas, a cada nova policy, caso você precise customizar, você poderá ver como está ficando um XML de customização de toda a configuração para você:
Configuração de Policies : Request==> Policies ===> Backend
Na seção de Backend, você irá apontar o destino do seu Backend. Que pode ser um Microserviço/Backend pronto, ou até mesmo uma Azure Logic Apps. Além do endereço, você ainda pode entrar com uma conta de usuário para autenticação HTTP Basic, ou até mesmo uma comunicação via certificado digital:
Configuração do Backend
Por último, assim como é possível adicionar politicas na chegada de dados, é possível também adicionar policies no retorno de dados, como por exemplo, adicionar cabeçalhos HTTP ou até mesmo outras políticas customizadas, veja a imagem a seguir:
Configuração de Policies na seção Outobund Processing
Como exemplo, vamos apenas adicionar um header customizado, como na imagem a seguir:
Adicionando um Header customizado
Finalizando nossa Publicação
Como passos finais, podemos ver configurações gerais de nossa API na aba Settings, de acordo com a imagem a seguir:
Configurações Finais da API
No passo Subscription required, por hora, vamos deixar desmarcado. Além disto, nós ainda poderiamos habilitar a monitoração e o serviço de Azure Insights para esta nossa API, que neste momento, estará desabilitado também. Veja na aba seguinte Test, o resultado de nossa execução:
Resultado executado com sucesso HTTP 200 – Nosso Backend retornou os dados de acordo
Aqui o resultado no console/terminal para ficar exatamente o mesmo da execução do nosso post anterior, porém, observe que temos um Header a mais que é retornado pela nossa policy:
Resultado de nosso Backend
Para este Backend, nós estamos executando um serviço em nosso IPaaS: Skalena Cloud, que possui um serviço Kubernetes que executa nossas integrações a partir de uma imagem Docker. Lembrando, que adicionamos uma Policy que cada IP só pode fazer 10 chamadas por minuto. Como é sempre muito importante ter seu backend e infraestrutura protegida, vamos ver o resultado ao tentar executar mais de 10 vezes a partir do mesmo ip:
Executamos o comando hey que por padrão envia 200 requests pro endereço, após isto, veja o resultado:
O ambiente do Azure API Manager, recusou o atendimento, nos retornando um erro HTTP 429, com o código dizendo que o limite da quota de acesso foi excedido.
Conclusão
O Azure API Manager tem várias funcionalidades que poderiam ser exploradas neste post, mas nós tentamos deixar muito próximo das capacidades apresentadas também no post anterior que falamos do AWS API Gateway.
Neste post nós usamos nossa própria camada de Backend as a Service da nossa solução Skalena Finance, que no caso do produto de Open Banking, combina alguns recursos e microserviços de MongoDB e APIs REST, ambos executados em nosso ambiente Kubernetes nuvem, porém, poderíamos também ter usado as capacidades do Azure Functions, que é o análogo ao AWS Lambda, porém, no ambiente da Microsoft.
Se você tiver interesse e precisa de mais informações, sobre este post e qualquer outro assunto relacionado a Microserviços, APIs, OpenBanking no Brasil, por favor, entre contato com nosso time comercial aqui neste endereço: skalena.com/contato ou através de nosso e-mail direto: contato (a) skalena.com
Um abraço do time Skalena!
Bonus
Métricas de Acesso aos Serviços
A cereja do bolo: API DevPortal
