Skip to content

07.md

Latest commit

 

History

History
416 lines (250 loc) · 28.6 KB

07.md

File metadata and controls

416 lines (250 loc) · 28.6 KB

Projeto 02 - Blog Pessoal - Classe PostagemController - Método Consultar todas as Postagens

O que veremos por aqui:

  1. Criar a Classe PostagemController
  2. Criar o Método getAll() para listar todas as Postagens

1. O Recurso Postagem

Nas duas etapas anteriores, iniciamos a construção do Recurso Postagem a partir da Classe Model Postagem, onde definimos todos os seus atributos e geramos a tabela tb_postagens no banco de dados db_blogpessoal.

Em seguida, implementamos a Interface PostagemRepository, responsável por disponibilizar todos os métodos necessários para interagir com o banco de dados.

Agora, vamos avançar para a criação dos 6 métodos da Classe Postagem, conforme ilustrado no diagrama de classes abaixo, implementando-os na Classe PostagemController.

classDiagram
    class Postagem {
        - Long id
        - String titulo
        - String texto
        - LocalDateTime data
        
        + getAll() ResponseEntity List ~Postagem~
        + getById(Long id) ResponseEntity ~Postagem~
        + getByTitulo(String nome) ResponseEntity List ~Postagem~
        + post(Postagem postagem) ResponseEntity ~Postagem~
        + put(Postagem postagem) ResponseEntity ~Postagem~
        + delete(Long id) void
    }
Loading

A Classe PostagemController será a controladora do recurso Postagem, ou seja, será responsável por receber e processar todas as requisições HTTP (HTTP Requests) enviadas de fora da aplicação para este recurso.

Dentro dessa classe, implementaremos:

  • Os métodos do CRUD (Create, Read, Update e Delete), herdados da Interface JpaRepository;
  • Os métodos personalizados (consultas específicas), definidos na Interface PostagemRepository.

👣 Passo 01 - Criar o Pacote Controller

Na Source Folder principal (src/main/java), já foram criados os seguintes pacotes da nossa aplicação:

  • Pacote Principal: com.generation.blogpessoal – contém a classe principal responsável por iniciar a aplicação.
  • Pacote Model: com.generation.blogpessoal.model – armazena as classes de modelo, que representam as entidades e suas propriedades.
  • Pacote Repository: com.generation.blogpessoal.repository – contém as interfaces responsáveis pela comunicação com o banco de dados.

Na figura abaixo, é possível visualizar a estrutura desses três pacotes:


ALERTA DE BSM: Mantenha a Atenção aos Detalhes ao criar a Camada Controller. Um erro muito comum é criar o pacote na Source Folder de Testes, ao invés de criar na Source Folder Principal.

Nesta etapa, vamos criar a Camada Controller:

  1. No lado esquerdo superior, na Guia Package explorer, clique com o botão direito do mouse sobre a Package com.generation.blogpessoal, na Source Folder src/main/java e clique na opção New 🡪 Package.
  1. Na janela New Java Package, no item Name, acrescente no final do nome da Package .controller, como mostra a figura abaixo:
  1. Clique no botão Finish para concluir.

Quando você terminar de criar a Camada Controller, a sua estrutura de pacotes ficará igual a figura abaixo:


👣 Passo 02 - Criar a Classe PostagemController na Camada Controller

Agora, vamos criar a Classe Controladora, que chamaremos de PostagemController.

  1. Clique com o botão direito do mouse sobre o pacote controller da aplicação ( com.generation.blogpessoal.controller).
  2. Na sequência, clique na opção New 🡪 Class
  1. Na janela New Java Class, no item Name, digite o nome da Classe (PostagemController), como mostra a figura abaixo:
  1. Clique no botão Finish para concluir.

Agora vamos começar a criar o código da Classe Controladora PostagemController:

Nesta primeira parte vamos criar a base da Classe Controladora:

Linha 1: Através do comando package, estamos informando o nome do pacote (camada), onde a Classe foi criada. Esta informação é inserida automaticamente pelo STS ao criar a Classe.

Linhas 3 a 13: Através do comando import, estamos indicando todos os pacotes que contém as Classes que estão sendo utilizadas na Classe PostagemController.

Linha 15: A anotação @RestController define que a Classe é do tipo RestController, que receberá requisições que serão compostas por:

  • URL: Endereço da requisição (endpoint)
  • Verbo: Define qual Método HTTP será acionado na Classe controladora.
  • Corpo da requisição (Request Body): Objeto que contém os dados que serão persistidos no Banco de dadas. Nem toda a requisição enviará dados no Corpo da Requisição.

Após receber e processar a requisição, a Classe Controladora responderá a todas as requisições com:

  • Um Código de Status HTTP pertinente a operação que está sendo realizada.
  • O resultado do processamento (Objetos de uma Classe, por exemplo) inseridos diretamente no corpo da resposta (Response Body)

Linha 16: a anotação @RequestMapping é usada para mapear as solicitações para os Métodos da Classe controladora PostagemController, ou seja, define a URL (endereço) padrão do Recurso (/postagens). Ao digitar a url do servidor seguida da url do Recurso (http://localhost:8080/postagens), o Spring envia a requisição para a Classe responsável pelo Recurso associado à este endereço.

Linha 17: a anotação @CrossOrigin indica que a Classe controladora permitirá o recebimento de requisições realizadas de fora do domínio (localhost e futuramente da nuvem quando o Deploy da aplicação for efetivado) ao qual ela pertence. Essa anotação é essencial para que o front-end ou o aplicativo mobile tenha acesso aos Métodos e Recursos da nossa aplicação (O termo técnico é consumir a API).

Além de liberar todas as Origens das requisições (parâmetro origins), a anotação libera também os Cabeçalhos das Requisições (parâmetro allowedHeaders), que em alguns casos trazem informações essenciais para o correto funcionamento da aplicação.

Cross-Origin: Configurar o Cross-Origin Resource Sharing (CORS) permite que uma classe controladora aceite requisições realizadas fora do domínio da aplicação. Em ambiente de desenvolvimento, o nosso domínio é localhost, mas futuramente será o endereço da aplicação hospedada na nuvem.

Ao ser adicionada na Classe Controladora, essa anotação é essencial para que o front-end, que será desenvolvido no próximo bloco, possa acessar e consumir a API. Além de liberar todas as origens das requisições (origins), ela também permite o acesso às propriedades do cabeçalho das requisições (allowedHeaders), que, em alguns casos, trazem informações críticas para o funcionamento correto da aplicação, como o Token de Autorização, que é utilizado para liberar o acesso a endpoints específicos de maneira segura.


Recomendação em produção: Ao migrar para um ambiente de produção, é altamente recomendado definir o endereço do deploy do front-end ou da aplicação mobile, que irão consumir o back-end, na anotação @CrossOrigin para restringir as origens permitidas e reforçar a segurança.

Exemplo:

// Configurando o CORS
@CrossOrigin(
    origins = {"http://localhost:5173", "https://blogpessoal.vercel.app"},
    allowedHeaders = "*"
)

No exemplo acima, a anotação @CrossOrigin permite requisições originadas do front-end em ambiente de desenvolvimento local (React rodando em localhost) e do endereço de produção hospedado na plataforma Vercel.


CORS na Prática

Enquanto você estiver rodando o back-end e o front-end localmente (localhost), não haverá nenhum problema, como mostra a imagem abaixo:

Todas as Requisições tem como origem o mesmo Servidor (localhost). Agora ao efetuar o Deploy, o seu front-end estará em um Servidor e o seu Back-end estará em outro:

No exemplo acima, o front-end está em um servidor diferente do back-end, logo quando o front-end enviar uma requisição para o back-end, você receberá uma mensagem de erro de CORS:

Access to fetch at 'http://frontend.vercel.app/postagens' from origin 'http://frontend.vercel.app' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Para evitar este erro e permitir o recebimento de Requisições HTTP de outras origens (servidores), habilitamos o CORS em todas as Classes Controladoras através da anotação @CrossOrigin.

Com o CORS habilitado, nosso back-end estará pronto para receber requisições do front-end.

Linhas 20 e 21: a anotação @Autowired (Injeção de Dependência), é a implementação utilizada pelo Spring Framework para aplicar a Inversão de Controle (IoC) quando for necessário. A Injeção de Dependência define quais Classes serão instanciadas e em quais lugares serão Injetadas quando houver necessidade.

Inversão de Controle ou Inversion of Control - conhecido pela Sigla IoC é um Pattern (padrão de código), que prega para usarmos o controle das instancias de uma determinada classe, devem ser tratadas externamente e não dentro da classe em questão, ou seja, Inverter o controle de uma classe delegando esta tarefa para uma outra classe, interface, componente, serviço, entre outros.

Injeção de Dependência ou Dependency Injection ou D.I é um tipo de Inversão de Controle, que propõe a inserção (injeção) de uma Classe dentro da outra, invertendo o seu controle. Com esta abordagem diminuímos o acoplamento entre as nossas Classes, facilitamos a manutenção, além de ser uma solução elegante.

Em nosso exemplo, a Classe Controladora cria um ponto de injeção da Interface PostagemRepository na Classe PostagemController. De acordo com o tipo de Requisição (Método HTTP) , que a Classe PostagemController receber, o Spring responderá de uma forma específica:

  • Quando a Classe PostagemController receber uma nova Requisição do tipo GET, ele executará uma Query Method (Método de Consulta) específica e caso a Consulta encontre os Objetos no Banco de dados, o Spring cria um novo Objeto ou uma Coleção de Objetos (Collection List) da Classe Postagem contendo o resultado da consulta e insere no Corpo da Resposta HTTP no formato JSON. Caso nada seja encontrado, ele retornará um objeto nulo (caso não esteja usando Optional) ou a Coleção vazia.

  • Quando a Classe PostagemController receber uma nova Requisição do tipo POST ou PUT ele cria um novo Objeto da Classe Postagem através do JSON enviado no Corpo da Requisição, que contém os dados do Objeto e persiste o Objeto através do Método save().

  • Quando a Classe PostagemController receber uma nova Requisição do tipo DELETE, ele executará o Método delete() e não retornará nada, por se tratar de um Método void.

Observe que o Objeto da Interface PostagemRepository, injetado na Classe PostagemController, permite o uso de todos os Métodos da Interface PostagemRepository (Métodos Padrão ou Personalizados), sem a necessidade de criar Métodos Construtores na Classe Model ou efetuar o processo manual de Criar e Instanciar Objetos (igual você fez em Java no Bloco I). A Injeção de Dependência transfere ao Spring a responsabilidade de criar e instanciar objetos da Classe Postagem, permitindo que nós, desenvolvedores, foquemos apenas no processamento das requisições HTTP.


O Spring Container é o núcleo do Spring Framework. Ele é responsável por criar, gerenciar e injetar objetos (beans) em sua aplicação. Esse comportamento é fundamentado no princípio da Inversão de Controle (IoC – Inversion of Control), onde o controle da criação e gerenciamento dos objetos deixa de ser do desenvolvedor e passa a ser do próprio framework.

Em resumo: você define o que deve ser criado, e o Spring define como e quando criar e fornecer esses objetos.

O que é um Bean no Spring?

No contexto do Spring, um bean é qualquer objeto Java instanciado e gerenciado pelo Spring IoC Container. Esses beans podem ser criados automaticamente a partir de anotações ou definidos manualmente em arquivos de configuração.

Como declarar um Bean?

Você pode registrar uma classe como um bean de forma automática utilizando anotações específicas:

  • @Component: marca uma classe genérica para ser gerenciada como bean.
  • @Service: semântica para classes de lógica de negócio (especialização de @Component).
  • @Repository: usada para classes de persistência. Além de ser um bean, ativa a tradução de exceções do Spring.
  • @RestController: para classes da camada de controle (web), também são beans.

Sobre repositórios no Spring Data JPA

No Spring Data JPA, quando você cria uma interface que estende JpaRepository, o Spring detecta automaticamente essa interface e cria uma implementação dinâmica em tempo de execução. Isso ocorre graças ao uso da anotação @EnableJpaRepositories, que já é ativada por padrão em aplicações Spring Boot.

Em outras palavras, você não precisa usar @Repository nas interfaces que estendem JpaRepository, pois o Spring já as registra como beans automaticamente durante a inicialização da aplicação.

Como o ciclo funciona no Spring Boot?

  1. Você cria as classes e marca com anotações como @Component, @Service ou @RestController, conforme o papel da classe.
  2. O Spring procura em todo o projeto (com base no @ComponentScan) e registra essas classes como beans no container.
  3. Sempre que uma dependência é necessária em outra classe, o Spring a injeta automaticamente, usando a anotação @Autowired em um objeto de uma destas classes ou através do método construtor, promovendo a injeção de dependência.


👣 Passo 03 - Criar o Método getAll()

Vamos implementar o Método getAll() na Classe Postagem Controller, que retornará todos os Objetos da Classe Postagem persistidos no Banco de dados. Traçando um paralelo com o MySQL, seria o equivalente a instrução: SELECT * FROM tb_postagens;.

Linha 23: a anotação @GetMapping mapeia todas as Requisições HTTP GET, enviadas para um endereço específico, chamado endpoint, dentro do Recurso Postagem, para um Método específico que responderá a requisição, ou seja, ele indica que o Método getAll(), responderá a todas as requisições do tipo HTTP GET, enviadas no endereço http://localhost:8080/postagens/.

ATENÇÃO: O Endereço do endpoint será igual ao Endereço do Recurso (@RequestMapping) apenas quando a anotação @GetMapping não possuir um endereço personalizado, como um parâmetro por exemplo. Caso existam dois ou mais Métodos do tipo GET será necessário personalizar o endereço de cada Método anotado com @GetMapping, pois não pode existir endereços duplicados.

Linha 24: O Método getAll() será do tipo ResponseEntity porquê ele responderá a Requisição HTTP (HTTP Request), com uma Resposta HTTP (HTTP Response).

✔: O Método além de retornar um objeto da Classe ResponseEntity (OK 🡪200), no parâmetro body (Corpo da Resposta), será retornado um Objeto da Classe List (Collection), contendo todos os Objetos da Classe Postagem persistidos no Banco de dados, na tabela tb_postagens. Observe que nesta linha foi utilizado um recurso chamado Java Generics, que além de simplificar o retorno do Objeto da Classe List, dispensa o uso do casting (mudança de tipos). Observe que na definição do Método foram utilizados os símbolos , onde T é o Tipo do Objeto que será retornado no Corpo da Resposta.

Linha 25: return ResponseEntity.ok(postagemRepository.findAll()); Executa o Método findAll() (Método padrão da Interface JpaRepository), que retornará todos os Objetos da Classe Postagem persistidos no Banco de dados (). Como a List sempre será gerada (vazia ou não), o Método sempre retornará o Status 200 🡪 OK.

Para concluir, não esqueça de Salvar o código (File 🡪 Save All)



👣 Passo 04 - Executar o projeto

  1. No Spring Boot Dashboard, como mostra a imagem abaixo, Selecione o Projeto que você deseja executar:
  1. Clique no botão Start para executar o Projeto.
  2. Observe que será aberta a janela Console com o log da execução do código. Caso esteja tudo certo, o Console exibirá no final do processamento a mensagem indicando que a aplicação está em execução (indicada em vermelho na imagem).

👣 Passo 05 - Inserir dados no Banco de dados

Como ainda não criamos um Método para Cadastrar Postagens (criaremos em breve), vamos inserir dois registros diretamente no Banco de Dados db_blogpessoal na Tabela tb_postagens para testarmos o nosso Método findAll().

  1. Abra o MySQL Workbench.

  2. No MySQL Workbench, Clique sobre a Conexão Local instance MySQL80

  3. Será aberta a janela principal do MySQL Workbench.

  4. Na Barra de Ferramentas Principal Crie um novo arquivo SQL (Query), clicando no ícone :

  5. Insira os comandos abaixo no arquivo:

USE db_blogpessoal;

INSERT INTO tb_postagens (data, texto, titulo) 
VALUES (current_timestamp(), 'Texto da postagem 01', 'Postagem 01');
INSERT INTO tb_postagens (data, texto, titulo) 
VALUES (current_timestamp(), 'Texto da postagem 02', 'Postagem 02');

SELECT * FROM tb_postagens;
  1. Clique no primeiro raio para executar a Consulta e inserir os dados no Banco de dados db_blogpessoal.
  1. A imagem acima mostra que os dados foram inseridos com sucesso!

👣 Passo 06 - Testar no Insomnia

Para testar a aplicação, utilizaremos o aplicativo Insomnia.



Vamos criar no Insomnia uma nova Collection, chamada Blog Pessoal, para guardar todas as nossas Requisições do Projeto Blog Pessoal. Na sequência vamos criar dentro da Collection Blog Pessoal uma pasta chamada Postagem para guardar todas as requisições do Recurso Postagem. Para concluir, vamos criar uma requisição do tipo GET, dentro da pasta Postagem, para testar o nosso Método getAll().

6.1. Criando a Collection Blog Pessoal

  1. Na janela principal do Insomnia, clique no botão Create e clique na opção Request Collection.
  1. Na janela que será aberta, informe o nome da Collection (Blog Pessoal) e clique no botão Create para concluir.

6.2. Criando a Pasta Postagem

Vamos criar dentro da Collection Blog Pessoal a Pasta Postagem, que guardará todas as requisições do Recurso Postagem.

  1. Na Collection Blog Pessoal, clique no botão . No menu que será aberto, clique na opção New Folder.
  1. Na janela que será aberta, informe o nome da pasta (Postagem) e clique no botão Create para concluir.

6.3. Criando a Requisição - Consultar todas as postagens

Agora vamos criar a Requisição para o Método getAll():

  1. Clique com o botão direito do mouse sobre a Pasta Postagem para abrir o menu e clique na opção New HTTP Request.
  1. Será criada uma nova Requisição (New Request) dentro da pasta Postagem.
  1. Dê um duplo clique sobre a nova requisição (New Request), informe o nome da requisição (indicado na imagem abaixo na cor amarela) e pressione a tecla enter do seu teclado.
  1. Selecione o Método HTTP que será utilizado (GET) na requisição, indicado na imagem abaixo na cor verde.
  1. Configure a requisição conforme a imagem abaixo:
  1. No item marcado em verde na imagem acima, informe o endereço (endpoint) da Requisição. A requisição Consultar Todas as postagens foi configurada da seguinte maneira:
  • A primeira parte do endereço (http://localhost:8080) é o endereço do nosso servidor local. Quando a API estiver na nuvem, ele será substituído pelo endereço da aplicação na nuvem.
  • A segunda parte do endereço é o endpoint configurado na anotação @RequestMapping, em nosso caso /postagens.

  1. Para testar a requisição, com a aplicação rodando, clique no botão .

  2. O resultado da requisição você confere na imagem abaixo:

  1. Observe que a aplicação além de exibir os dados de todos os Objetos da Classe Postagem persistidos no Banco de dados, no Corpo da Resposta, ela também retornará um HTTP Status 200 🡪 OK (indicado em verde na imagem acima), informando que a Requisição foi bem sucedida!
  2. Caso o Projeto Spring não esteja em Execução, o Insomnia retornará a mensagem abaixo:
  1. Execute o seu Projeto e teste novamente!