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 <a href="/blog/tudo-que-eu-sei-spring-boot-ca">tudo sobre Spring Boot</a> e o <a href="/blog/curso-gratis-spring-boot-para-">curso grátis de Spring Boot</a>.
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
spring.h2.console.enabled=true ).model para as entidades
e repository para os repositórios Spring Data JPA.Cliente e Contato com as anotações JPA/Lombok necessárias.ClienteRepository e ContatoRepository estendendo JpaRepository .ClienteController para expor
endpoints POST e GET de clientes e contatos diretamente.@RequestBody , @PathVariable e @ResponseEntity para
recebimento/retorno dos dados e status HTTP corretos.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: <em>ID (auto-incrementado), nome e e-mail</em> ; O Contato possui <em>ID, tipo, valor</em> e uma associação a um cliente. Use anotações <code>@Entity</code> , <code>@Table</code> , <code>@Id</code> , <code>@GeneratedValue</code> , <code>@OneToMany</code> / <code>@ManyToOne</code> conforme a direção do relacionamento. Recomenda-se <code>fetch = FetchType.EAGER</code> no lado do cliente para carregar contatos juntos e <code>LAZY</code> no contato.
Importante
Lembre-se de também colocar as anotações <code>@JsonManagedReference</code> e <code>@JsonBackReference</code> nos relacionamentos para evitar loops de serialização nas respostas JSON.
Endpoints REST essenciais
Rode sua API com os seguintes endpoints básicos:
201 Created404 se o cliente não existir)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)
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 <code>@NotNull</code> , 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 <a href="/blog/desafio-dos-inscritos-code-rev">arquitetura limpa em Spring Boot</a> e <a href="/blog/aprenda-isso-no-spring-e-se-to">tópicos avançados de Spring</a>.
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).
<a href="https://spring.io/projects/spring-boot">Spring Boot — spring.io</a>. <a href="https://endoflife.date/spring-boot">End-of-life Spring Boot</a>.
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.