HelpDesk RESTful API

Projetos

A HelpDesk RESTful API é um projeto de transformação criado para consolidar os conhecimentos adquiridos em Spring Framework. A API consiste no backend de uma aplicação de gerenciamento de chamados. O projeto utiliza Spring Boot, Spring Web, Spring Data, Spring Validation, Spring Security, Spring Test, JWT e Servidor de Recursos Oauth 2. A aplicação segue as melhores práticas de desenvolvimento de APIs RESTful, retornando sempre códigos de status HTTP apropriados para cada tipo de operação.

A aplicação possui controle de autenticação e autorização, tendo, portanto, áreas que só podem ser acessadas por usuários autenticados de determinado perfil. Todo usuário ao ser cadastrado recebe um perfil, podendo este variar entre cliente, técnico ou administrador:

Além dos perfis de usuário, a aplicação possui dois perfis de inicialização. No perfil test a aplicação utiliza um banco de dados H2; no perfil dev, um banco de dados MySQL. É possível alterar facilmente o perfil de inicialização da aplicação modificando apenas a propriedade spring.profiles.active — do arquivo de configuração application.properties.

A HelpDesk RESTful API é uma joia do tratamento de exceção, que em caso de erro informa o código de retorno, o tipo do erro, a descrição do erro e os atributos preenchidos de forma inválida.

Exemplo Tratamento de Exceção

O projeto possui testes de unidade detalhados, além de uma carga inicial de dados de teste que permitem facilmente testar no Postman, assim que a aplicação é inicializada.

Construída entre 07/12/2022 e 12/02/2024, um ano e três meses, consumiu ao final, 185 horas de trabalho divididas em quatro etapas:

  1. Baseada no curso Formação Angular + Spring Boot (Ûdemy - Valdir Cezar)

    A etapa 1 definiu o conceito do projeto e criou a parte inicial do código da aplicação:

    • Camada model
    • Mapeamento de entidades com JPA
    • Camada DTO
    • Camada controller
    • Camada service
    • Camada repository
    • Enumerações
    • Perfis de inicialização da aplicação (dev e test)
  2. Transformação

    A etapa 2 foi o início da transformação do projeto:

    • No projeto original, a aplicação utiliza apenas um objeto DTO para cada model. Em decorrência, a camada controller não retorna o DTO do Cliente ou do Tecnico cadastrado ou atualizado no sistema — retorna apenas o códigos de status HTTP da operação. Isso porque retornar o DTO significa também retornar sua senha — mesmo criptografada, retornar a senha do usuário é uma falha grave de segurança.

      O projeto transformado utiliza um objeto DTO para o request e outro para o response. Dessa forma, ClienteRequestDTO e TecnicoRequestDTO possuem o atributo senha. ClienteResponseDTO e TecnicoResponseDTO não. Isso permite retornar o DTO do Cliente ou do Tecnico cadastrado ou atualizado no sistema sem expor sua senha.

    • No projeto original, ao criar ou atualizar um Cliente, é possível passar na requisição um array de perfis. Isso permite na prática criar ou modificar um Cliente de modo que o mesmo acumule os perfis cliente, técnico e administrador. Isso configura uma falha grave de segurança pois, de acordo com as regras de negócio, o próprio cliente pode realizar ou modificar seu cadastro no sistema — dessa forma, o próprio cliente pode se presentear com superprivilégios.

      No projeto transformado, o service que atende a requisição não permite que o Cliente cadastrado ou alterado acumule perfis. Dessa forma, mesmo enviando um array de perfis na requisição, no final da operação, o Cliente terá apenas o perfil cliente.

    • No projeto original, todo Técnico cadastrado recebe automaticamente os perfis cliente e técnico — entretanto, isso é feito na camada DTO.

      No projeto transformado, isso fica a cargo do service — separando assim, a camada de transporte de dados das regras de negócio.

    • No projeto transformado, as enumerações foram retiradas da camada domain e alocadas na raiz do projeto — ficando assim, mais fácil de serem encontradas.
    • No projeto transformado, a camada domain foi renomeada para model — ficando assim, mais fácil de ser encontrada.
    • No projeto transformado, a classe UserSS (que implementa UserDetails) deixou a pasta security (excluída da aplicação) para ser alocada na pasta model (junto com os demais models do sistema).
  3. Baseada na trilogia de vídeos Spring Security & JSON Web Tokens (Youtube - Dan Vega)

    Na etapa 3 foi construída a autenticação com Spring Security + JWT e a autorização com Servidor de Recursos Oauth 2.

  4. Baseada no curso Testes automatizados na prática com Spring Boot (Ûdemy - Giuliana Silva Bezerra)

    Na etapa 4 foi construído:

    • Os diagramas de cenário de teste — elegantemente confeccionados no Corel Draw e exibidos na galeria de imagens do projeto.
    • Os testes de unidade com Spring Boot.

    Nesta etapa também foi definido os códigos de status HTTP apropriados para cada tipo de operação — inclusive para o tratamento de exceção.

Para Saber Mais