Construção de uma WEB API em ASP.NET Core 3.1 com Entity Framework e MVC [Parte 1]
Bem vindos de volta à série de artigos sobre C# e .NET Core. Com esse artigo daremos continuidade à criação de uma solução de cadastro simples, mas desta vez com o formato REST API, que dentro do universo de desenvolvimento da Microsoft é chamado de WEB API, mas obedecendo os mesmos princípios.
Iremos construir uma solução REST (GET/POST/PUT/DELETE) para o controle de Produtos, semelhante à solução do artigo anterior, mas não ficaremos restritos ao modelo e ao controlador, sem construir, por enquanto, nenhuma funcionalidade para visualizarmos o CRUD.
Ainda iremos documentar nossa API com seus respectivos endpoints utilizando o Swagger, testar as entradas com o Postman e aproveitaremos para abordar os conceitos de uma solução REST e aprender boas práticas em sua construção.
Parte 1:
- Um pouco sobre REST
- Recurso
- Criação do projeto no Visual Studio 2019
- Configurações
- Camadas da aplicação
- Testando a API com Postman
Parte 2:
- Migrações (EF Migrations)
- Relacionamentos One-to-Many
- Padronizando o retorno da camada de dados
- Ajustando o Controlador de Produtos
- Documentando a API
Um pouco sobre REST
REST é um acrônimo para REpresentational State Transfer. É um estilo arquitetural ideal para sistemas distribuídos, onde as regras de negócio e acesso à base são desacopladas dos sistemas de interface com o usuário.
Assim como outros estilos arquiteturais, o REST também possui seus fundamentos que devem ser atendidos por uma solução de uma API caso queiramos que ela seja tratada como RESTful. Abaixo estão estes princípios:
- Client–server — Ao separar as responsabilidades da interface do usuário das com o armazenamento de dados e com o tratamento da lógica do negócio, deixando isso a cargo da API, aprimoramos a portabilidade da interface do usuário para várias plataformas e melhoramos a escalabilidade , simplificando os componentes do servidor.
- Stateless — Cada solicitação do cliente para o servidor deve conter todas as informações necessárias para entender a solicitação e não pode tirar proveito de nenhum contexto armazenado no servidor. O estado da sessão é, portanto, mantido inteiramente no cliente.
- Cacheable — As restrições de cache exigem que os dados em uma resposta a uma solicitação sejam implicitamente ou explicitamente rotulados como armazenáveis em cache ou não em cache. Se uma resposta for armazenável em cache, o cache do cliente terá o direito de reutilizar esses dados de resposta para solicitações posteriores equivalentes.
- Uniform interface — O REST é definido por quatro restrições de interface: identificação de recursos; manipulação de recursos através de representações; mensagens auto-descritivas; e hipermídia como o mecanismo do estado do aplicativo.
- Layered system — O estilo do sistema em camadas permite que uma arquitetura seja composta de camadas hierárquicas, restringindo o comportamento do componente, de modo que cada componente não possa “ver” além da camada imediata com a qual está interagindo.
- Code on demand (opcional) — O REST permite que a funcionalidade do cliente seja estendida baixando e executando o código na forma de applets ou scripts. Isso simplifica os clientes, reduzindo o número de recursos necessários para a pré-implementação.
Recurso
Recurso é um conceito abstrato que denota uma funcionalidade ou grupo de funcionalidades anotada por um ponto de entrada. A disponibilidade que um Controlador cria para que, por meio de uma URL. No caso deste artigo, estamos tratando do recurso produto acessado pelo endpoint /api/produtos e cada um dos verbos HTTP.
Criação do projeto no Visual Studio 2019
Depois dessa introdução teórica vamos ao momento prático, a criação, configuração, construção e teste da API.
Passo 1 — Arquivo -> Novo -> Projeto -> Aplicativo ASP.NET Core:
Passo 2 — Informar o nome do projeto e o diretório do seu workspace
Passo 3 — Escolher API e clicar em Criar
Configurações
Para informar em que porta nossa aplicação será disponibilizada, vamos abrir o arquivo launchsettings.json e incluir o as configurações abaixo:
Camada do Modelo
Vamos descrever agora o modelo que representa a tabela de Produtos.
Contexto da Aplicação
Crie a pasta Context e adicione uma nova classe ApplicationDbContext.cs que servirá como intermediadora entre a base de dados e nossa aplicação. Nele teremos o DbSet<Produto> que terá seu escopo acessado no serviço responsável pelas regras de negócio relacionadas ao Produto. Como a nossa aplicação é bem simples, não teremos nenhuma regra complexa associada e os métodos dentro dos serviços serão de simples comunicação com o Contexto.
Camada de Serviços
Idealizada para apoiar o Controlador com o acesso à base(embora possamos utilizar o Contexto da aplicação no controlador), a camada de serviços oferece bem mais do que uma intermediação. Para aplicações complexas, com mais detalhes de regras de negócio, essa camada é uma forma de acessar não somente a lógica de negócio refletida nas entidades, mas classes que detenham um comportamento complexo de um domínio, por exemplo, ou que descrevam um algoritmo que diz respeito a um fluxo específico. Para o nosso exemplo trataremos apenas de métodos de acesso ao Contexto, mas a ideia é evoluir este projeto, então daremos uma atenção especial a esta camada mais tarde.
Agora precisamos adicionar, na classe Startup.cs, a injeção de dependência para o serviço responsável pelas operações CRUD de produto:
Controlador de Produtos
Para adicionar um novo controlador, clique com o botão direito sobre a pasta Controller -> Controlador. Selecione Controlador API — Vazio e Adicionar.
Informe o nome do controlador ProdutoController.cs e Adicionar
Agora é necessário adicionar ao controlador de produtos, os métodos responsáveis por tratar cada uma das requisições HTTP assinaladas anteriormente.
Testando a API com Postman
Nossa API trabalha com cinco endpoints que representam as formas básicas de manipulação de dados de uma tabela, o CRUD (Create/Read/Update/Delete), que são:
HTTP GET: api/produtos/(Para recuperar todos os produtos)HTTP GET: api/produtos/{id}(Para recuperar um produto específico)HTTP POST: api/produtos/(Para salvar um produto novo)HTTP PUT: api/produtos/{id}(Para alterar um produto existente)HTTP DELETE: api/produtos/{id}(Para remover um produto existente)
Antes de testar os endpoints, é necessário rodar a aplicação para que fique disponível na porta 5000, configurada no arquivo launchsettings.jso. Pra isso temos que ir no diretório raiz da aplicação usando o PowerShell, Cmder ou o console de comandos que você preferir e rodar o comando dotnet run.
Pronto, agora executaremos o Postman, uma excelente ferramenta de testes de requisições HTTP para fazer as chamadas a cada endpoint da API de Produtos. Escolha o devido método HTTP (GET/POST/PUT/DELETE) e informe os caminhos que a API disponibiliza.
- GET: http://localhost:5000/api/produtos
Vamos enviar essa requisição HTTP GET sem informar nada no Body. O resultado será uma listagem no formato JSON com todos os registros da tabela de Produto que nossa aplicação recuperou.
Informando um id de um produto no final da URL buscamos um único registro de um produto.
Vamos realizar essa requisição HTTP POST informando os dados de um produto no body e também setando o tipo de objeto que estamos enviando nessa requisição, no caso JSON.
Com o método/verbo HTTP PUT e informando o id ao final da URL atualizamos um registro de produto.
Com o método/verbo HTTP DELETE e informando o id ao final da URL removemos um registro de produto.
Próxima etapa:
No parte 2 deste artigo abordaremos migrações, documentação da API e a organização dos códigos de resposta em cada um dos endpoints e a comunicação com o repositório de produtos.
