/compasso-avaliacao

Desenvolvimento de uma aplicação em Spring Boot que possui três endpoints

Primary LanguageJava

Avaliação Sprint 4

Desenvolva uma aplicação em Spring Boot que possua três endpoints

Exemplo da request

1. Pessoa

a. POST /pessoa

  • No corpo da requisição é enviado o nome, cpf, salário e os outros atributos conforme a imagem acima.
  • O armazenamento de dados pode ser feito no banco de dados h2, ou a sua escolha.
  • Todos os campos não podem ser nulos, e precisam ser validados com a anotação @Valid no endpoint e inserindo o @NotBlank em cada campo.
  • Para inserir dados de pessoa, não pode ser mapeado na classe de domínio Pessoa.
    • Exemplo: PessoaForm() ou PessoaRequest()
  • O qual será responsável por capturar os dados do corpo da requisição.
  • Como a pessoa tem relação de 1 para n com o endereco, é necessário fazer um form e um dto também.
  • Para a resposta, é ncessário utilizar o padrão DTO (Data Transfer Object) para manipular os responses dos serviços.
  • Para essa requisição, mapear o array de endereços na requisição de inserção de pessoa.
  • Uma dica antes de enviar a pessoa para o banco: enviar primeiro o endereço, capturar o endereço salvo no banco, inserir no relacionamento da pessoa e depois enviar a pessoa com sua relação endereço para o banco de dados.
    • Exemplo: 
      Pessoa pessoa = pessoaForm.save(pessoa,pessoaRepository,enderecoRepository);
      • Dentro do método save, realizar a inclusão do endereço com a pessoa.
    • Exemplo de inserção: 
      Endereco enderecoSaved = enderecoRepository.save(pessoa.getEndereco());
Pessoa pessoa = new Pessoa(enderecoSaved)
Pessoa pessoaSaved = pessoaRepository.save(pessoa);
      • Já que o endereço é um array, é ncessário fazer o getOne dentro do for, capturar o endereço salvo no banco e gravar no arraylist para enviar no final a pessoa com todos os endereços de uma só vez.
      • E retornando a pessoa salva no banco no formato DTO, onde somente se deseja mostrar o nome da pessoa, cpf, cidade e rua.
  • Exemplo de response

b. GET /pessoa

  • Nesse método verificar se existe pessoas cadastradas, se existir retornar o ResponseEntity.ok, se não existir retornar o ResponseEntity.notFound.
  • A resposta dever ser feita no formato DTO mapeando somente os atributos do response exemplo acima.

c. GET /pessoa/{id}

d. PUT /pessoa/{id}

e. DELETE /pessoa{id}

Para realizar alteração e exclusão, coloque a anotação @Transactional, pois essas classes tem relação com outra classe, e o endereco. Para realizar a exclusão da pessoa, é preciso excluir o endereço, o qual tem a relação @OneToMany, sendo necessário mapear a exclusão em cascata, pois se excluir a pessoa, não faz sentindo deixar o endereço dele no banco.

  • Exemplo: @OneToMany(cascade = CascadeType.REMOVE)

2. Produto

a. POST /produto

  • No corpo da requisição é enviado a descrição e o preço unitário.
  • Todos os campos não podem ser nulos, e precisam ser validados com a anotação @Valid no endpoint e inserindo o @NotBlank em cada campo.
  • Para inserir dados do produto, não pode ser mapeado na classe de domínio Produto.
    • Exemplo: ProdutoForm() ou ProdutoRequest()
  • Onde será responsável por capturar os dados do corpo da requisição.
  • Para a resposta, deseja-se utilizar o padrão DTO (Data Transfer Object) para manipular os responses dos serviços.
  • Para realizar o cadastro do produto, antes será preciso se autenticar no endpoint /auth, onde retornará um token, que será passado por baixo como Bearer Token.

  • Para, enfim, enviar o produto na base de dados.

  • Depois de realizer o envio do produto, retornar o seguinte response no formato produtoDto com o status code 201 created:

b. GET /produto

  • Nesse método verificar se existe produtos cadastrados, se existir retornar o ResponseEntity.ok, se não existir retornar o ResponseEntity.notFound.
  • A resposta dever ser feita no formato DTO mapeando somente os atributos do response exemplo acima.

c. GET /produto/{id}

d. PUT /produto/{id}

e. DELETE /produto{id}

  • No método delete, realizar o delete soft, não deletando o produto e sim alterando ele como status desativado, usando uma variável booleana para ativar e desativar a visualização do produto.

3. Pedido

a. POST protected/pedido

  • No corpo da requisição é enviado os ids dos produtos, para buscar os produtos cadastrados para realizar o pedido.

  • Para inserir dados do produto, não pode ser mapeado na classe de domínio Pedido.
    • Exemplo: PedidoForm() ou PedidoRequest()
  • Onde será responsável por capturar os dados do corpo da requisição.
  • Para a resposta, deseja-se utilizar o padrão DTO (Data Transfer Object) para manipular os responses dos serviços.
  • Para realizar o cadastro do pedido, antes será preciso se autenticar no endpoint /auth, onde retornara um token, que será passado por baixo como Bearer Token.

  • Para, enfim, enviar o pedido na base de dados.

  • Cada id simboliza um produto

    • 1 – Arroz
      • R$ 10.00
    • 2 – Feijão
      • R$ 5.00
    • 3 – Açucar
      • R$ 3.50
    • 4 – Lentilha
      • R$ 4.00

  • Dando o total no pedido de 22.50, no momento de salvar calcular o total de produtos que tem no array e inserir no pedido, junto com a data atual.

  • Depois de realizar o envio do pedido retornar o seguinte response no formato pedidoDto com o status code 201 created:

b. GET protected/pedido

  • Nesse método verificar se existe pedidos cadastrados, se existir retornar o ResponseEntity.ok, se não existir retornar o ResponseEntity.notFound.
  • A resposta dever ser feita no formato DTO mapeando somente os atributos do response exemplo acima.

c. GET protected/pedido/{id}

d. PUT protected/pedido/{id}

e. protected/pedido/{id}

No método delete, realizar o delete soft, não deletando o pedido e sim alterando ele como status desativado, usando uma variável booleana para ativar e desativar a visualização do pedido. Para permitir os acessos aos métodos protegidos, é ncessário habilitar o acesso nas configurações de segurança.

Como parte do trabalho e como uma forma de documentar a API, crie a documentação dela pelo Swagger.

Ferramentas e dependências utilizadas

Java Badge Spring Badge Eclipse Badge Postman Badge Git Badge

  • Spring Initializr: gera um projeto de Spring Boot com dependências iniciais de forma rápida. Todas as dependências se encontram no arquivo pom.xml.
    • Projeto Maven com Spring Boot versão 2.5.2 e Java versão 11.
    • Spring Data JPA: persiste dados em SQL com Java Persistence API usando Spring Data e Hibernate.
    • Validation: Bean Validation com validador do Hibernate.
    • Spring Web: cria aplicações web, incluindo RESTful, usando Spring MVC, utilizando o Apache Tomcat como contêiner integrado padrão.
    • Spring cache abstraction: fornece operações relacionadas ao cache, como a capacidade de atualizar o conteúdo do cache, mas não fornece o armazenamento de dados reais.
    • Spring Security: autenticação altamente personalizável e estrutura de controle de acesso para aplicações Spring.
    • Spring Boot Actuator: suporta endpoints integrados (ou personalizados) que permitem monitorar e gerenciar a aplicação - como a integridade, métricas, sessões, etc.
    • SpringFox: documentação de API JSON automatizada para APIs construídas com Spring
    • Spring Boot DevTools: fornece reinicializações rápidas de aplicativos, LiveReload e configurações para uma experiência de desenvolvimento aprimorada.
    • H2 Database: fornece um banco de dados em memória que suporta acesso JDBC API e R2DBC, com um aplicativo de console baseado em navegador.
    • Java JWT: JSON Web Token: o JJWT pretende ser a biblioteca mais fácil de usar e compreensível para criar e verificar JSON Web Tokens (JWTs) na JVM e Android.
    • As configurações do DataSource, JPA e H2 se encontram no arquivo application.properties.
    • Os registros do banco de dados utilizados como teste se encontram no arquivo data.sql.
  • Eclipse IDE for Java EE Developers: ferramentas para desenvolvedores Java criando aplicativos Java EE e Web, incluindo Java IDE, ferramentas para Java EE, JPA, JSF, Mylyn, EGit e outros.
  • Postman: plataforma de colaboração para desenvolvimento de API, utilizado para requisições do tipo GET/POST/PUT/DELETE.
  • Git: sistema de controle de versão distribuído gratuito e de código aberto.
  • Swagger: simplifica o desenvolvimento de API, ajudando a projetar e documentar APIs. A documentação criada para esse projeto se encontra em swagger-openapi.yaml.

Configurações

  • Foi utilizado profiles para simular ambientes de produção e de desenvolvimento.
    • Para testar o ambiente de produção (autenticação ativada) com o Profile("prod"), é necessário configurar os argumentos da VM com o comando -Dspring.profiles.active=prod
    • Para o ambiente de desenvolvimento (autenticação desabilitada) com o Profile("dev"), usa-se a configuração -Dspring.profiles.active=dev.
  • Para deletar os dados dos endpoints, é nécessário possuir a autenticação de moderador.
  • Para consultar a documentação Swagger automatizada do SpringFox, basta acessar o seguinte endereço (considerando que a aplicação esteja utilizando a porta 8080): http://localhost:8080/swagger-ui.html.
  • Obs.: as senhas criptografadas dos usuários criados para testes são "123456".