ASP.NET Core e Refit: simplificando a comunicação entre APIs

Neste artigo, falarei sobre o Refit, uma biblioteca incrível!

Já precisou implementar comunicação entre os serviços de sua arquitetura utilizando .NET? Nesse cenário, o Refit se destaca!

Usando ele, você reduzirá bastante o código utilizado para integração com outras APIs de sua arquitetura de serviços/microserviços.

Código-fonte em https://github.com/luisdeol/artigo-refit

A biblioteca Refit

O Refit é uma biblioteca que permite representar uma REST API através de uma interface.

Confuso? Creio que seja melhor explicar com um exemplo concreto!

Imagine a seguinte situação:

  • Uma API Orders precisa processar um pagamento de um pedido, e para isso ele delegará a transação a outra API Payments;
  • A comunicação é síncrona, e através de uma chamada HTTP;
  • Logo, será necessário: implementar um método, criar o objeto HttpClient, obter a URL, realizar a requisição, e finalmente deserializar o objeto recebido.

As mesmas operações se repetiriam para cada chamada dessa comunicação entre os serviços. Um pouco repetitivo, certo? Por mais que esses comportamentos sejam extraídos para um método à parte, ainda assim se nota redundância de código.

O Refit permite que esse processo todo seja simplificado através da definição de uma interface, que poderá ser chamada das classes clientes. Isso resulta em uma redução de código incrível.

Por exemplo, no exemplo desse artigo, a seguinte interface representa o API Payments:

Interface referente ao serviço Payments

Ficou bem legível, certo? É definido o tipo de retorno, o método HTTP utilizado, os parâmetros, e a rota além da base (será mostrado mais para frente como definir a rota base).

E não, não será necessário implementar ela!

Instalação da biblioteca

Os pacotes NuGet necessários para esse artigo são:

  • Refit.HttpClientFactory

Utilizei o ASP.NET Core 2.2 para esse exemplo, e a versão usada desse pacote é a 4.7.51.

Instalando o pacote via dotnet CLI

Com a biblioteca instalada, podemos começar a implementação.

Implementando a comunicação entre os serviços

A comunicação a ser implementada se dará entre dois serviços: Orders e Payments.

O Orders vai receber o pedido de processamento de pagamentos, e delegará isso para o serviço Payments. Ele também realizará consultas no Payments para saber o estado atual do pagamento.

O código abaixo se refere ao OrdersController, que está no serviço ExemploRefitApis.Orders.

Implementação do OrdersController

Como mostrado anteriormente, o IPaymentsService, que é a interface que representa a API Rest ExemploRefitApis.Payments, é definida utilizando o Refit.

Definição do serviço REST Payments

A definição dos endpoints da API, a serem acessados, é feita com o uso das anotações Get e Post. Os parâmetros da chamada, tanto os da URL quanto o corpo da requisição, são definidos como parâmetros do método.

Definida a interface do serviço REST, é necessário configurar o uso do Refit na classe Startup do projeto que o utilizará. Especificamente, essa configuração será feita no método ConfigureServices.

A URL base poderá ser armazenada no arquivo appSettings.json, em uma variável de ambiente, ou ainda no Azure Key Vault.

Configuração do Refit na classe Startup

Finalmente, segue abaixo a implementação do controller Payments do serviço de mesmo nome.

Implementação do PaymentsController, do serviço REST Payments

Com os devidos preparativos feitos, é hora de testar a comunicação entre os serviços! Isso pode ser feito utilizando o Postman, ou o REST Client (extensão do Visual Studio Code).

Nesse exemplo, utilizo o Postman. Realizo a requisição GET na imagem abaixo.

Requisição HTTP GET ao serviço Orders

Defini um ponto de interrupção, o que mostra que o objeto foi retornado com sucesso desde o serviço Payments.

Ponto de interrupção mostrando o sucesso da comunicação com o serviço Payments

Tudo correto até então! Com isso, confirmamos que os serviços estão devidamente configurados, e que a comunicação entre eles está funcionando.

Após isso, é testado o método HTTP POST, do serviço Orders. Novamente, é utilizado o Postman.

Requisição HTTP POST ao serviço Orders

Novamente, defini um ponto de interrupção, o que mostra que o objeto foi retornado com sucesso desde o serviço Payments.

Ponto de interrupção mostrando o sucesso da comunicação com o serviço Payments

Perfeito! Ambos endpoints estão acessíveis desde o serviço Orders, ao serviço Payments.

Quer alavancar sua carreira como Desenvolvedor(a) .NET?

Além de Desenvolvedor .NET Sênior, eu sou instrutor de mais de 700 alunos e também tenho dezenas de mentorados.

Conheça o Método .NET Direto ao Ponto, minha plataforma com mais de 800 videoaulas, com cursos cobrindo temas relacionados a linguagem C# e Programação Orientada a Objetos, APIs REST com ASP NET Core, Microsserviços com ASP NET Core, HTML, CSS e JavaScript, Desenvolvimento Front-end com Angular, Desenvolvimento Front-end com React, JavaScript Intermediário, TypeScript, Formação Arquitetura de Software, Microsoft Azure, Agile, SQL, e muito mais.

Inclui comunidade de centenas de alunos, suporte por ela, plataforma e e-mail, atualizações regulares e muito mais.

Clique aqui para ter mais informações e garantir sua vaga

Nesse artigo, foi apresentado o Refit, junto a um exemplo completo de seu uso. O código para comunicação entre os dois serviços foi substancialmente reduzido graças a ele, sem ter a legibilidade degradada.

Código-fonte em https://github.com/luisdeol/artigo-refit

Até o próximo artigo!