TADS · Desenvolvimento de Sistemas Web

Simulado — Spring Boot API

REST com Spring MVC, persistência com JPA/Spring Data JPA e autenticação com Spring Security + JWT. Baseado no conteúdo ministrado na disciplina DSW.

20 questões ~15 min Nível Intermediário Origem DSW

Ver escopo

Estrutura

Como o conteúdo se conecta

O fluxo de uma API Spring Boot típica — da requisição até o banco de dados — organiza os capítulos deste simulado.

01Fundamentos Spring
Bean · IoC · DI

02Controller REST
Rotas · Verbos HTTP

03Validação
Bean Validation

04JDBC & ORM
Conceitos de base

05JPA
Entidades · Relações

06Spring Data JPA
Repository · Query

07Security/JWT
AuthN · AuthZ

Capítulos

Temas cobrados

Distribuição das questões por área temática.

Fundamentação teórica

Camadas de persistência: do JDBC ao Spring Data JPA

ORM é uma técnica; JPA é a especificação de como aplicar essa técnica em Java; Hibernate é uma das bibliotecas que implementam essa especificação; e Spring Data JPA é um módulo do Spring que simplifica o uso do JPA — sem fazer parte do Jakarta/Java EE.

Camada	O que é	Responsabilidade
JDBC	API de baixo nível para conexão e execução de SQL	Abrir/fechar conexão, montar `PreparedStatement` e mapear manualmente cada linha do `ResultSet` para um objeto
ORM	Técnica/conceito (Object-Relational Mapping)	Definir como registros de tabelas se convertem em objetos, sem detalhar a implementação
JPA	Especificação Jakarta Persistence, parte do Jakarta EE	Padronizar anotações (@Entity, @Id...), o EntityManager e a linguagem JPQL, sem amarrar a um SGBD
Hibernate	Implementação (provider) do JPA	Traduzir as operações do EntityManager em SQL de fato; é a implementação usada pelo Spring Boot
Spring Data JPA	Módulo do Spring (não é parte do JEE)	Eliminar boilerplate: gera repositórios e queries a partir de interfaces e nomes de método

Por que isso importa No JDBC puro, cada consulta exige abrir conexão, escrever o SQL, iterar o ResultSet e popular o objeto manualmente. O ORM (via JPA/Hibernate) automatiza esse mapeamento: o desenvolvedor manipula objetos Java e o provider gera o SQL por trás. O Spring Data JPA vai um passo além, eliminando também a escrita repetitiva de métodos de CRUD e consultas simples.

Fundamentação teórica

Bean, IoC e Injeção de Dependência

A base do Spring Framework é o container de IoC (Inversion of Control): em vez de a própria classe criar suas dependências com new, é o container que cria, configura e entrega os objetos prontos para uso.

O que é um Bean Bean é o termo do Spring para um objeto cuja criação e ciclo de vida são gerenciados pelo container — e não pelo próprio desenvolvedor. Uma classe se torna elegível a virar Bean principalmente de duas formas:

@Component (ou suas especializações @Service, @Repository, @Controller/@RestController) — marca a própria classe para ser detectada e instanciada pelo component scan.
@Bean — anotação usada em métodos dentro de uma classe de configuração (@Configuration), retornando o objeto que deve ser registrado como Bean.

Um Bean não é um arquivo de configuração, uma tabela de banco ou um endpoint — é sempre um objeto gerenciado pelo container.

Injeção de Dependência (DI): construtor vs. atributo O Spring resolve as dependências entre Beans automaticamente (Dependency Injection), e isso pode ser feito de formas diferentes:

@Autowired em atributo — funciona, mas esconde as dependências dentro da classe e dificulta a criação de instâncias em testes sem subir o container.
Injeção via construtor — é a forma recomendada em projetos novos: deixa explícito quais dependências são obrigatórias, permite declarar os atributos como final (imutáveis) e facilita a criação de testes unitários passando os mocks diretamente pelo construtor, sem depender do Spring.

As duas formas funcionam tecnicamente em versões atuais do Spring — a diferença é de clareza de design e testabilidade, não de disponibilidade do recurso.

Fundamentação teórica

Escopos de Bean no Spring

O escopo define quantas instâncias de um Bean existem e por quanto tempo elas vivem. Fora do Singleton (padrão), os demais escopos exigem um contexto web ativo.

Escopo	Características	Depende de contexto web?
Singleton	Uma única instância por aplicação — é a configuração padrão quando nenhum escopo é indicado	Não
Prototype	Cada injeção/acesso gera um novo objeto	Não
Request	Bean criado e mantido durante o processamento de uma única requisição HTTP	Sim
Session	Bean criado e mantido durante a sessão de um usuário	Sim
Application	Bean criado uma vez por aplicação rodando dentro de um contexto web (equivalente ao ServletContext)	Sim
Websocket	Bean criado e mantido durante uma sessão acessada via Websocket	Sim

Fundamentação teórica

Controllers REST: rotas, verbos e anotações

Uma API REST expõe recursos através de URLs e verbos HTTP, retornando dados (geralmente JSON) no corpo da resposta — diferente de uma aplicação MVC tradicional (SSR), em que o Controller retorna o nome de uma view a ser renderizada no servidor.

Verbo HTTP	Operação	Status de sucesso típico
GET	Consultar um recurso ou coleção	200 OK
POST	Incluir um novo recurso	201 Created, com o cabeçalho `Location` apontando para a URI do recurso criado
PUT	Atualizar (substituir) um recurso existente	200 OK ou 204 No Content
DELETE	Remover um recurso	204 No Content

Principais anotações

@RestController — equivale a @Controller + @ResponseBody aplicado a todos os métodos: o valor retornado é serializado diretamente como corpo da resposta HTTP (normalmente JSON), em vez de ser interpretado como o nome de uma view.
@PathVariable — captura um valor a partir do próprio caminho da URL, como o {id} em /produtos/{id}.
@RequestParam — lê parâmetros enviados via query string (ex.: /produtos?categoria=roupas).
@RequestBody — converte o corpo da requisição (JSON) em um objeto Java.

Stateless Uma API REST é dita stateless quando o servidor não mantém nenhum estado de sessão do cliente entre requisições: cada requisição deve trazer, por si só, todas as informações necessárias para ser processada (incluindo credenciais/token de autenticação, quando aplicável).

Fundamentação teórica

Validação de dados com Bean Validation

O Bean Validation (parte da especificação Jakarta) permite declarar regras de validação diretamente nos atributos das classes, usando anotações. O Spring integra essas anotações ao fluxo de requisições REST.

Anotação	Regra validada
@NotNull	O valor não pode ser nulo
@NotBlank	String não pode ser nula, vazia ou só espaços
@Size	Tamanho mínimo/máximo de uma String, coleção etc.
@Email	Formato válido de e-mail
@Min / @Max	Valor numérico mínimo/máximo permitido
@Past	A data deve ser anterior ao momento atual (ex.: data de nascimento)
@Future	A data deve ser posterior ao momento atual
@Pattern	O valor deve casar com uma expressão regular

@Valid e mensagens customizadas

Quando @Valid é usado junto de @RequestBody no parâmetro de um método, o Spring aciona a validação de todas as anotações de Bean Validation presentes na classe do objeto recebido, retornando erro 400 automaticamente caso alguma restrição seja violada.
Para customizar as mensagens de erro (por exemplo, para internacionalização/i18n) usando um arquivo de mensagens (resource bundle), é preciso registrar um MessageSource associado a um LocalValidatorFactoryBean, através de bean.setValidationMessageSource(messageSource). As chaves de mensagem usadas nas anotações seguem o formato {chave-mensagem}.

Fundamentação teórica

Mapeamento de entidades com JPA

Cada entidade JPA é uma classe Java anotada que representa uma tabela do banco de dados; seus atributos representam as colunas e os relacionamentos entre entidades representam chaves estrangeiras (ou tabelas associativas).

Anotação	Para que serve
@Entity / @Table	Marca a classe como entidade e, opcionalmente, define o nome da tabela mapeada
@Id	Marca o atributo que representa a chave primária da entidade
@GeneratedValue	Indica que o valor da chave primária será gerado automaticamente
@Column	Customiza detalhes da coluna mapeada (nome, tamanho, obrigatoriedade)
@Transient	Marca um atributo que existe na classe Java, mas não deve ser persistido no banco de dados

Relacionamento	Uso
@ManyToOne	Usado do lado "muitos" de uma relação um-para-muitos — ex.: cada `ImagemProduto` pertence a um único `Produto`
@OneToMany(mappedBy = ...)	Usado do lado "um" da mesma relação, referenciando o atributo dono do relacionamento do outro lado
@ManyToMany + @JoinTable	Relação muitos-para-muitos; `@JoinTable` define o nome da tabela intermediária e suas colunas de junção (`joinColumns` e `inverseJoinColumns`)
@OneToOne	Relação um-para-um entre duas entidades

Referência rápida

Formas de consulta com JPA

Comparativo entre as quatro abordagens de consulta vistas no material.

Abordagem	Como funciona	Quando usar
Query Methods	Spring Data JPA gera a query a partir do nome do método (ex: `findByLastnameAndFirstname`)	Consultas simples, sem escrever SQL/JPQL manualmente
JPQL (@Query)	Query escrita à mão referenciando entidades e atributos Java, não tabelas do BD	Consultas mais elaboradas, ainda portáveis entre bancos
Criteria API	Consulta construída dinamicamente via código Java, com tipagem em tempo de desenvolvimento	Filtros dinâmicos/condicionais complexos
@NativeQuery	SQL nativo do banco, referenciando tabelas/colunas reais	Recursos específicos do SGBD que o JPQL não cobre

Boas práticas no Spring

spring.jpa.open-in-view vem habilitado por padrão, mantendo a conexão aberta durante toda a requisição — não é recomendado para produção.
Alternativas: escrever JOIN FETCH nas consultas, usar Entity Graph, ou representar o retorno com DTOs em vez das entidades diretamente.
fetch = EAGER resolve o sintoma, mas pode causar o problema N+1 — prefira LAZY combinado com uma das alternativas acima.

Interface	O que adiciona
Repository	Interface raiz "marcadora", sem métodos próprios
CrudRepository	Estende Repository; adiciona métodos básicos de CRUD (save, findById, findAll, delete...)
PagingAndSortingRepository	Estende CrudRepository; adiciona `findAll(Sort)` e `findAll(Pageable)`, com suporte a ordenação e paginação
JpaRepository	Estende PagingAndSortingRepository; adiciona operações específicas do JPA (flush, batch delete etc.)

Query Methods Ao declarar um método de repositório seguindo a convenção de nomes do Spring Data JPA (ex.: findByLastnameAndFirstname), o próprio Spring Data interpreta o nome do método — o prefixo findBy, os nomes dos campos da entidade e palavras-chave como And/Or/Between — e gera automaticamente a query JPQL correspondente, sem exigir implementação manual.

Fundamentação teórica

Autenticação e autorização com Spring Security e JWT

Em uma API REST stateless, a autenticação costuma ser feita por token: o cliente envia usuário/senha uma única vez, recebe um token JWT (JSON Web Token) e passa a enviá-lo no cabeçalho Authorization em cada requisição subsequente.

Estrutura de um JWT Um token JWT é uma string dividida em três partes separadas por pontos, sempre na ordem Header.Payload.Signature:

Header — metadados do token, como o algoritmo de assinatura usado.
Payload — os claims: dados do usuário e demais informações que o token carrega (ex.: id, papéis/roles, data de expiração).
Signature — assinatura que garante que o conteúdo do token não foi alterado após ser emitido.

Fluxo de autenticação stateless Depois que o JWT é emitido, o servidor não precisa consultar novamente o banco de dados (ou a senha) a cada requisição: basta validar a assinatura e a expiração do token e confiar nas informações (claims) nele contidas. É essa autocontenção do token que permite que a API continue stateless, sem manter sessão do usuário no servidor.

Simulado

Teste seus conhecimentos

20 questões de múltipla escolha, uma alternativa correta cada.

Pronto para começar? Você pode revisar o feedback de cada questão antes de avançar.

Fontes

Este resumo foi elaborado a partir do conteúdo teórico da disciplina de Desenvolvimento de Sistemas Web (DSW), organizado nos sete temas abaixo, com apoio da documentação oficial do Spring.

BOOT Spring Boot Reference IOC IoC Container & Beans JPA Spring Data JPA Reference SEC Spring Security Architecture VAL Bean Validation Specification REST HATEOAS

Baseado no conteúdo da disciplina Desenvolvimento de Sistemas Web (DSW), ministrada pelo Prof. Fernando Tsuda, e na documentação oficial do Spring (links acima).

Os slides e materiais da disciplina DSW são de uso exclusivo dos alunos matriculados no curso e não são redistribuídos neste site — o conteúdo acima é um resumo teórico próprio, elaborado apenas para fins de estudo e revisão.