Solucionado
Olá! Passando por essa parte de omitir o atributo da senha, queria saber se seria possível ou se não seria uma boa prática com Quarkus usar o padrão DTO, criando as classes de request e response e mapeando de modo a não repassar a própria entidade nas requisições, como é comum em aplicações Spring Boot, por exemplo? Ou com Quarkus já não seria uma prática comum de se fazer?
Parabéns ao instrutor pelas aulas, curtindo bastante aprender sobre o framework.
Oi Giovani,
Independente do framework, é sempre uma boa ideia não devolver entidades JPA pela API, para se ter um melhor controle dos dados que ela recebe/devolve.
Nesses casos utilizar o padrão DTO acaba sendo uma boa solução, pois te permite ter esse controle, além de também permitir flexibilidade com a criação de diversos DTOs distintos para cada situação.
Mas lembre-se que toda solução sempre terá seus prós e contras, cabendo ao time avaliar quando vale a pena utilizar cada uma. No caso do padrão DTO um contra é que você precisa escrever mais código na sua API, aumentando assim o trabalho de manutenção. Um dica seria utilizar alguma biblioteca de mapping de objetos, como o ModelMapper ou MapSctuct
Bons estudos!
Oi, Rodrigo,
Boa, valeu a resposta. Sempre penso nessa de evitar expor entidades, mesmo tendo o contra de digitar mais, a IDE e as bibliotecas fazem quase tudo para nós heheh perguntei porque pensei que houvesse uma outra forma de lidar com esse padrão pelo Quarkus.
Valeu a ajuda!