Desafio Spring Boot: mini CRM Cliente e Contato
Resolva o desafio de vaga júnior: mini CRM com Cliente e Contato, Spring Boot, JPA, H2 e endpoints REST claros.
Por que isso é importante
Este desafio Spring Boot mini CRM (vaga júnior) pede um mini CRM em Java Spring Boot: entidades Cliente e Contato (um-para-muitos), Spring Data JPA, H2 e endpoints REST com status HTTP corretos. Abaixo: requisitos, camadas e o que avaliadores costumam pontuar.
O desafio: mini CRM com Cliente e Contato
O desafio de vaga Java Spring Boot pede um mini CRM: API REST com Cliente e Contato
(um-para-muitos), Spring Data JPA, H2 e status HTTP corretos — sem Service/DTO. Ideal
para júnior mostrar CRUD e relacionamento (@OneToMany)s. Para base teórica, veja
tudo sobre Spring Boot e o
curso grátis de Spring Boot.
Requisitos e critérios de aceite
O sistema precisa controlar duas entidades principais: Cliente (com ID,
nome, e-mail) e Contato (ID, tipo, valor, cliente). A relação é de um para muitos : um cliente pode ter vários contatos. Tudo isso deve ser
feito sem camadas intermediárias como DTO ou Service, para garantir aprendizado puro de
controller e repositório.
Atenção
Não utilize camadas de serviço (service) ou transformação de objetos (DTO). A entrega
dos dados será feita diretamente pelo corpo das entidades via request/response!
Stack: Spring Boot, JPA e H2
Java 17+
Versão da linguagem para base do Spring Boot
Maven
Gerenciador de dependências do projeto Java
Spring Boot 4.0+ (ou 3.5.x só se o desafio exigir)
Framework para criação da API REST
Spring Web
Módulo para criação dos endpoints HTTP
Spring Data JPA
ORM de persistência e consultas
Banco H2
Banco de dados em memória, ideal para testes
Lombok
Simplifica geração de getters/setters/construtores
Spring Boot DevTools
Auto-reload e melhorias no dev
Dica
Use o Spring Initializr para gerar rapidamente seu projeto e as dependências
principais!
Passo a passo: criar o projeto
- Passo 1: Gere o projeto no Spring Initializr ,
selecionando Java 17+, Maven, Spring Boot 4.0+ (3.5.x chegou ao fim do suporte OSS em jun/2026 — use só se o enunciado da vaga exigir), Spring Web, Data JPA, H2, Lombok
e DevTools. - Passo 2: Extraia e abra o projeto em sua IDE favorita (ex:
IntelliJ, VS Code). - Passo 3: Configure o application.properties para conectar ao banco H2 em memória, habilitando o console web (
spring.h2.console.enabled=true). - Passo 4: Crie os packages
modelpara as entidades
erepositorypara os repositórios Spring Data JPA. - Passo 5: Modele as entidades
ClienteeContatocom as anotações JPA/Lombok necessárias. - Passo 6: Implemente as interfaces
ClienteRepositoryeContatoRepositoryestendendoJpaRepository. - Passo 7: Crie o
ClienteControllerpara expor
endpoints POST e GET de clientes e contatos diretamente. - Passo 8: Utilize
@RequestBody,@PathVariablee@ResponseEntitypara
recebimento/retorno dos dados e status HTTP corretos. - Passo 9: Teste a API com ferramentas da IDE ou pelo console
H2/Web, garantindo que os endpoints respondem como esperado. - Passo 10: Verifique que regras de resposta HTTP (201, 200, 404)
estão corretas para cada cenário.
Atenção
Proibido vincular contatos na criação do cliente! O contato é sempre cadastrado
depois, usando o ID do cliente já existente.
Camadas: Controller → Service → Repository
Organize o código em camadas claras mesmo no desafio júnior: Controller (HTTP), Service (regra), Repository (persistência). Isso é o que muitos avaliadores olham além do “subiu na porta”.
Evite regra de negócio dentro do controller e acesso JDBC solto espalhado.
O que cada camada faz neste desafio
Controller: mapeia HTTP, status codes, DTOs de entrada/saída — sem regra de negócio
Service: cria relacionamento (@OneToMany) Cliente↔Contato, valida existência, orquestra
Repository: Spring Data JPA — find/save; sem SQL solto no controller
Mesmo em mini CRM júnior, avaliador experiente abre o pacote e procura essa separação. God-controller com EntityManager no meio do POST perde ponto fácil.
Entidades: Cliente, Contato e relacionamento (@OneToMany)
O Cliente possui: ID (auto-incrementado), nome e e-mail ; O Contato possui ID, tipo, valor e uma associação a um cliente.
Use anotações @Entity , @Table , @Id , @GeneratedValue , @OneToMany / @ManyToOne conforme a
direção do relacionamento. Recomenda-se fetch = FetchType.EAGER no lado do
cliente para carregar contatos juntos e LAZY no contato.
Importante
Lembre-se de também colocar as anotações @JsonManagedReference e @JsonBackReference nos relacionamentos para evitar loops de serialização
nas respostas JSON.
Endpoints REST essenciais
Rode sua API com os seguintes endpoints básicos:
- POST /clientes : cria um cliente (sem contatos!) - retorna
201 Created - GET /clientes : lista todos os clientes com seus contatos
- POST /clientes/id/contatos : adiciona contato a um cliente
existente, via body (retorna404se o cliente não existir) - GET /clientes/id/contatos : lista contatos de um cliente pelo
seu ID
Atenção ao Status HTTP
Use sempre ResponseEntity para controlar o status de resposta: 201 para criação, 200 para busca com sucesso e 404 quando não encontrado.
Opções para vincular Contato ao Cliente
POST /clientes/{id}/contatos
Contato criado passando ID do cliente na URL via PathVariable.
+ Prós
- • URL clara e intuitiva
- • Facilita identificação do cliente
- • Adere a boas práticas REST
− Contras
- • Pouco flexível para casos futuros de múltipla associação
POST /contatos?clienteId=
Contato criado usando request param na query string.
+ Prós
- • Facilita consumo via formulários simples
- • Menos verbosidade na rota
− Contras
- • Menos intuitivo em APIs RESTful
- • Pode confundir em rotas semânticas
Recomendação
Prefira a abordagem POST /clientes/ {id} /contatos ; ela segue o
padrão de agrupamento de recursos e deixa o endpoint mais semântico.
Como testar os endpoints
Use funcionalidades da IDE, ferramentas como Postman, Insomnia ou até o próprio console
do H2 para criar, buscar e validar as respostas dos endpoints. Garanta que cada resposta
HTTP está correta, e que buscas por cliente inexistente retornam 404 .
Atenção
Não deixe dados mockados em código: teste sempre trabalhando com a requisição HTTP
real, simulando uso na prática!
Como avaliadores costumam pontuar
O desafio avaliará: Modelagem correta das entidades (relacionamentos e integridade) Endpoints REST funcionais e claros Status HTTP adequados nas respostas Boas práticas no código, evitando anti-patterns Aqui, clareza de código, simplicidade e aderência aos requisitos contam mais do que
soluções complexas.
Atenção ao Detalhe
Capriche na nomeação de métodos, rotas, campos e comentários. A clareza conta pontos!
Rubrica típica (ajuste ao enunciado da vaga)
- Modelo: Cliente 1—N Contato com FK/cascade coerente
- REST: verbos e paths claros; 201 create, 200/204 ok, 404 not found
- Camadas presentes e nomes legíveis
- H2 sobe e endpoints testáveis sem drama
- README com como rodar (porta, profile, exemplos curl)
- Sem overengineering (Kafka “porque sim” não ajuda júnior)
Diferencial: testes de um service ou MockMvc em 1–2 fluxos críticos. Clareza > framework obscuro. Entregue o que o PDF pediu primeiro.
Diferenciais que melhoram a nota
Para além do básico, você pode surpreender adicionando validações simples com @NotNull , mensagens de erro amigáveis, e organização do código pensando em
fácil escalabilidade (ex: modularização dos packages). Use o Lombok moderadamente e
mantenha o foco na robustez e clareza.
Cuidado
Não aumente a complexidade com patterns ou recursos avançados: respeite sempre o
escopo júnior quando indicado no desafio!
Conclusão: pronto para o desafio júnior
Seguindo este guia, você demonstrará domínio prático de CRUD com relacionamentos em Java
Spring Boot, manipulando endpoints REST, entendendo erros e aplicando boas práticas
essenciais. Este tipo de entrega sólida aumenta sua visibilidade entre recrutadores e
prepara para desafios ainda mais complexos em back-end. Quando o escopo crescer, estude
arquitetura limpa em Spring Boot e
tópicos avançados de Spring.
Dica para sua entrevista
Tenha o código rodando em local ou repositório público (ex: GitHub) e prepare
explicações claras sobre decisões de modelagem e arquitetura.
Fontes
Versões de Spring Boot e suporte OSS mudam. Em agosto de 2026, o artigo recomenda Spring Boot 4.0+ para projetos novos; 3.5.x só se o brief da vaga exigir (com atenção ao fim do suporte OSS).
Perguntas frequentes
O que costuma cair num desafio Spring Boot júnior de mini CRM?
API REST de Cliente e Contato com CRUD, relacionamento (ex.: OneToMany), Spring Data JPA, validação e status HTTP corretos. Muitas provas usam H2 em memória para facilitar a correção.
Qual versão de Spring Boot usar no desafio?
Prefira Spring Boot 4.0+ em projetos novos em 2026, com Java 17+. Se o enunciado fixar 3.5.x, siga o brief — mas saiba que 3.5 entrou em fim de suporte OSS em meados de 2026.
Como modelar Cliente e Contato no JPA?
Cliente como entidade raiz e Contato com FK para Cliente (OneToMany/ManyToOne). Exponha endpoints claros (ex.: POST/GET /clientes e /clientes/{id}/contatos) e valide campos obrigatórios antes de persistir.
Preciso de frontend no desafio de vaga?
Na maioria dos desafios júnior de backend, não: entregue API documentada (Postman/Swagger) e README de como subir. Só implemente UI se o enunciado pedir.
Continue explorando
Para API REST em outro stack, veja como criar API REST com Node.js. Na carreira, use o roadmap de desenvolvedor e o panorama de salário de desenvolvedor. Os cursos CrazyStack cobrem o caminho full stack.
Checklist de Implementação
- Projeto criado e dependências instaladas pelo Spring Initializr
- Banco de dados em memória H2 configurado e acessível
- Entidades Cliente e Contato modeladas corretamente
- Repositories JPA criados e funcionando
- Controller expõe todos os endpoints obrigatórios
- Status HTTP atendem aos critérios (201, 200, 404)
- API testada via ferramentas externas ou IDE
- Código limpo, sem camadas extras, no padrão do desafio
Perguntas frequentes
O que costuma cair num desafio Spring Boot júnior de mini CRM?
API REST de Cliente e Contato com CRUD, relacionamento (ex.: OneToMany), Spring Data JPA, validação e status HTTP corretos. Muitas provas usam H2 em memória para facilitar a correção.
Qual versão de Spring Boot usar no desafio?
Prefira Spring Boot 4.0+ em projetos novos em 2026, com Java 17+. Se o enunciado fixar 3.5.x, siga o brief — mas saiba que 3.5 entrou em fim de suporte OSS em meados de 2026.
Como modelar Cliente e Contato no JPA?
Cliente como entidade raiz e Contato com FK para Cliente (OneToMany/ManyToOne). Exponha endpoints claros (ex.: POST/GET /clientes e /clientes/{id}/contatos) e valide campos obrigatórios antes de persistir.
Preciso de frontend no desafio de vaga?
Na maioria dos desafios júnior de backend, não: entregue API documentada (Postman/Swagger) e README de como subir. Só implemente UI se o enunciado pedir.
Como testar os endpoints
Use funcionalidades da IDE, ferramentas como Postman, Insomnia ou até o próprio console do H2 para criar, buscar e validar as respostas dos endpoints. Garanta que cada resposta HTTP está correta, e que buscas por cliente inexistente retornam 404 .
Como avaliadores costumam pontuar
O desafio avaliará: Modelagem correta das entidades (relacionamentos e integridade) Endpoints REST funcionais e claros Status HTTP adequados nas respostas Boas práticas no código, evitando anti-patterns Aqui, clareza de código, simplicidade e aderência aos requisitos contam mais do que soluções complexas. Diferencial: testes de um service ou MockMvc em 1–2 fluxos críticos. Clareza > framework obscuro. Entregue o que o PDF pediu primeiro.