Skip to content

Latest commit

 

History

History
179 lines (111 loc) · 10.6 KB

DESAFIOS.md

File metadata and controls

179 lines (111 loc) · 10.6 KB

DESAFIOS

Esse arquivos contem sugestões de desafios para melhorar a API contida nesse repositório.

Após cada parte deste desafio, como entrega da atividade, enviar o link do repositório criado (no LinkedIn ou por email).

O que melhorar nesta API?

Antes de você começar a melhorar essa API REST, recomendo ler os artigos abaixo para alinhar o conhecimento sobre Java, REST, Spring, SOLID e o padrão MVC (Model View Controller):

1️⃣ Primeira parte

Na primeira parte desse desafio, o objetivo vai ser de atualizar a estrutura do projeto, e completar o CRUD (Create, Read, Update e Delete) do Controller.

Versionando seu código

Tarefa 🔀

  • O versionamento do nosso código é algo muito importante, para cada tarefa que está sendo solicitada for concluída, faça um commit para o seu repositório.

Referência a respeito do GIT

Camada de Service

Tarefa 🔛

  • Crie uma camada de Service para ser usada entre a camada de Controller e de Repository.
    • Atual: Controller --> Repository
    • Esperado: Controller --> Service --> Repository

Usar uma camada de Service é uma boa prática para separar as responsabilidades no projeto, pois as regras de negocio serão implementada nesta camada no lugar de ficar na camada de Controller (que tem como responsabilidade de ser a camada de entrada e saida de dados).

Referência a respeito de separação de conceitos

CRUD completo

Tarefa 🚀

  • Complete o CRUD com os endpoints de UPDATE e DELETE usando o CPF como PathVariable.
    • Atual: POST + GET
    • Esperado: POST + GET + PUT + DELETE

2️⃣ Segunda parte

Uso de DTO

Vamos agora aplicar o conceito de DTO (Data Transfer Object) ao nosso projeto. Para não utilizar as nossas Entidades como objeto de entrada e saida do nosso projeto. Isso é geralmente considerado uma boa prática no desenvolvimento de API para evitar manipular dados desnecessarios ou retornar dados sigilosos.

Seguem algumas referências a respeito:

Tarefa 🏗

  • Crie os DTOs para usar como objetos de requisição (UserForm) e respostas (UserResponse) na camada de Controller, e faça a adequação dos objetos (DTO para Entidades e vice versa) na camada de Service.

Uso de anotações de validações

Quando usamos DTOs, queremos aproveitar para validar que os dados enviados para nossa API sejam válidos. Para isso, podemos usar anotações que podem avaliar o formato nos quais os campos foram preenchidos.

Seguem algumas referências a respeito:

Tarefa ♻️

  • Atualize as anotações necessárias para validar o formato dos campos de CPF, EMAIL e NOME do DTO de requisição (UserForm).

3️⃣ Terceira parte

Tratamento de Exceções

Queremos que nossa API sejam fácil de uso e clara no seu funcionamento para quem for consumir ela. Para isso, é importante garantir que os erros esperados e/ou inesperados sejam tratados de forma amigáveis. Uma boa prática é usar Exception Handlers para isso.

Seguem algumas referências:

Tarefa 🔎

  • Crie uma classe de Exception Handler para retornar mensagens e http status amigáveis caso erros esperados ou inesperados ocorram no uso da sua API.

Testes Unitários

Testes unitários aumentam a qualidade de nosso código, eles testam o funcionamento de nossos métodos, um cenário de cada vez (sucessos e erros).

Seguem algumas referências:

Tarefa ⚙️

  • Implementar os testes unitários da camada de Service e de Controller da API.

4️⃣ Quarta parte

Documentação

Uma das habilidades mais importantes que um bom profissional de software deve ter é da escrita de documentações de alta qualidade. Para muitos, essa é uma tarefa difícil e traumática. Por exemplo, se uma API não for bem documentada, provavelmente, seus usuários encontrarão dificuldades para entender o seu funcionamento. Isso certamente influenciará na utilização dos serviços oferecidos em sua API.

Seguem algumas referências a respeito do Swagger, uma ferramenta permitindo você automatizar a criação da sua documentação:

Tarefa 📚

  • Automatizar a documentação dos endpoints da API usando Swagger.

5️⃣ Quinta Parte

Após ter implementado as 4 primeiras partes do desafio com um CRUD completo de gerenciamento de usuário, escolhe qual tipo de API desenvolver baseado nele, dentro da lista abaixo:

6️⃣ Sexta Parte

Caso tenha implementado a quinta parte toda e quiser ir além, segue um sugestão de melhoria do nível 2 (API de cadastro de endereços)

💡 Bônus

Quando trabalhamos com Java e Banco de Dados (BDD), é muito importante ter um conhecimento básico sobre SQL pois é necessário interagir com o BDD no cotidiano para buscar informações ou resolver problemas.

Seguem algumas referências a respeito: