ocrisurbainski / spring-webflux-sample Goto Github PK

• Normalmente pela especificação REST, os recursos seriam definidos sempre no plural, nunca no singular.

Sugeriria a subistituição de /people por /peoples

• Os objetos de entrada e saída mudam por motivos diferentes, o fato de manter uma única classe para represetnar o input e output aumenta a chance de uma quebra de funcionalidade em caso de mudança e quebra o SRP do SOLID.

Sugeriria você ter classes únicas para representar os inputs e outputs para cada tipo de recurso exposto na API

Exemplo: CreatePleopleRequest, CreatePeopleResponse, UpdatePeopleRequest, UpdatePeopleResponse e assim sucessivamente.

• Separar a documentação da API do código do controlador REST facilida a legibilidade e manutenção, mantém responsabilidades isoladas.

Sugeriria criar uma interface para concentrar as anotações do Open API e implementar a mesma no controlador REST por meio de sobrescrita, fiz um único comentário mas é válido para todos os métodos expostos da API

• Seguindo a especificação REST da definição de recursos estarem sempre no plural, não faz sentido ter uma rota GET people/all pois na definição de GET /peoples já é explícito o retorno.

Sugeriria remover o /all

Aqui mesmo sendo um exemplo para praticar seria interessante fornecer a possibilidade de realizar a busca baseado em alguns filtros e devolver o resultado dentro de uma paginação.

• O uso de parâmetro booleano apesar de facilitar a implementação ele dificulta a legibilidade, pois ao olhar a chamada do método obrigatoriamente eu preciso ir até o método para entender o que ele está fazendo.
• Outro ponto é que o uso de parâmetro booleano faz com que o método save tenha 2 responsabilidades, salvar e atualizar, seguindo o RSP do SOLID ambos mudam por motivos diferentes, logo uma alteração no método salvar pode quebrar 2 funcionalidades, no seu caso, inserir e atualizar.

Sugeriria a implementação de 2 métodos distintos, um para salvar e outro para atualizar, mesmo que tenham uma semelhança entre si e cause o sentimento de código repetido você garante o isolamento da responsabilidade

• Normalmente os métodos de criação ao serem invocados devolvem na resposta um Header de nome Location que contém o endereço URI para realizar a busca no recurso recém criado.

Sugeriria utilizar o ResponseEntity para montar a resposta adicionando o Header Location

• Essa Facade parece não estar sendo utilizada em nenhum lugar do projeto, se for o caso, poderia remover, ou se ela deveria ser utilizada, verificar o que está sendo injetado nas camadas externas.