# O que estudar antes de Spring Boot: um caminho prático para sair do tutorial

Descubra o que estudar de Java, HTTP e SQL antes de Spring Boot, com tarefas de diagnóstico, um projeto incremental e critérios para avançar.

Por Bruno Rana

Publicado em: 2026-10-22
Atualizado em: 2026-10-23

Artigo original: https://dev.buildrun.com.br/blog/o-que-estudar-antes-spring-boot/

**Para começar Spring Boot, você precisa conseguir acompanhar uma regra pequena em Java: de onde vêm os dados, o que o método faz e qual resultado ele devolve.** HTTP e SQL entram aos poucos, conforme você transforma esse programa em uma aplicação. Não precisa esperar conhecer toda a linguagem para criar o primeiro endpoint.

Talvez você consiga repetir o tutorial, mas fique sem direção quando alguém pede um filtro diferente. Vamos usar justamente essa mudança para organizar os estudos. Em vez de acumular uma lista de assuntos, você vai construir um catálogo de livros e observar o que falta para dar o próximo passo.

Você pode usar o roteiro depois das primeiras aulas ou ao retomar os estudos. A cada etapa, tente executar a tarefa, explicar o resultado e mudar uma condição. A dificuldade que aparecer ajuda a escolher o próximo assunto.

## Qual base de Java preciso antes de Spring Boot?

Comece com um catálogo de livros em memória. Cada livro tem identificador, autor e status de leitura: `NAO_INICIADO`, `EM_LEITURA` ou `CONCLUIDO`. A primeira tarefa é encontrar os livros de um status, sem servidor nem banco.

Para não depender de dados vagos, use este conjunto fictício durante o artigo:

| ID | Livro | Autor | Status |
| --- | --- | --- | --- |
| 11 | Jardim de inverno | Ana | `EM_LEITURA` |
| 12 | Caminhos da cidade | Ana | `CONCLUIDO` |
| 13 | Uma tarde no parque | Rui | `EM_LEITURA` |

Se você buscar `EM_LEITURA`, espera receber os IDs 11 e 13. Anote isso antes de implementar. Quando o resultado vier diferente, terá uma referência para investigar.

| Conceito | Tarefa de diagnóstico | Sinal de que precisa revisar |
| --- | --- | --- |
| Variáveis, condições e métodos | Receber um status e devolver o resultado de uma busca. | Não sabe distinguir argumento, variável local e retorno. |
| Objetos | Criar livros diferentes e alterar somente um deles. | Mudar um registro afeta outro sem intenção. |
| Coleções | Percorrer a coleção e selecionar os livros de um status. | Não consegue explicar por que um item entrou no resultado. |
| Ausência e erros | Tratar identificador inexistente e status inválido. | O programa encerra sem uma decisão clara sobre a falha. |
| Testes | Conferir resultado com nenhum, um e vários livros correspondentes. | Só verifica a tela ou o caminho de sucesso. |
| Ferramenta de build | Executar e testar o projeto fora da IDE. | Não sabe quais dependências e versão de Java o projeto usa. |

Não precisa resolver tudo sem consulta. Se uma linha travar, estude o conceito necessário e retome a mesma tarefa. O [índice oficial de aprendizado Java](https://dev.java/learn/) reúne referências de linguagem, orientação a objetos, exceções e coleções. Use-o para preencher a lacuna identificada, sem transformar cada capítulo em condição para avançar.

### Como estudar objetos sem decorar definições

Desenhe dois livros com identificadores diferentes e acompanhe o que acontece ao marcar um como concluído. Explique quais dados pertencem à instância e qual parte do programa decide alterar o status. Depois investigue como a coleção mantém referências para esses objetos.

Encapsulamento ajuda a manter essas mudanças sob controle. Suponha que, neste exercício, só um livro `EM_LEITURA` possa passar para `CONCLUIDO`. Se qualquer parte do programa alterar o status diretamente, cada uma precisará lembrar da regra. Ao concentrar a mudança em uma operação que a valida, fica mais fácil manter o comportamento consistente.

Você não precisa criar muitas classes para demonstrar isso. Comece por uma divisão que consegue explicar e reveja-a quando o programa trouxer outra necessidade.

### Como usar uma falha para orientar o estudo

Provoque um erro apenas no projeto de treino. Leia a mensagem, localize uma chamada do seu código na stack trace e siga a sequência que levou até ela. Separe a causa da falha dos pontos pelos quais a exceção passou.

Se a aplicação não iniciou por incompatibilidade de versão, resolva o ambiente primeiro. Isso é diferente de não compreender a regra de filtragem. Registrar essas duas categorias evita refazer aulas de linguagem para tentar corrigir uma ferramenta.

## O que entender de HTTP antes do primeiro controller

Aprenda a reconhecer método, caminho, parâmetros, corpo, status e conteúdo da resposta. No catálogo, a consulta por status pode chegar como um parâmetro na URL. A aplicação precisa converter essa entrada para uma representação que sua regra compreenda.

Para o exercício, defina um contrato antes do controller:

| Pedido | Decisão didática para a resposta |
| --- | --- |
| Listar livros com status reconhecido | Sucesso e uma lista, mesmo quando vazia. |
| Listar com status desconhecido | Erro de entrada com mensagem que explique o campo. |
| Buscar um identificador que não existe | Resposta de recurso não encontrado. |
| Consultar sem filtro | Listar todos os livros do pequeno conjunto de estudo. |

No exemplo, `GET /livros?status=EM_LEITURA` deve trazer os livros 11 e 13. Já `GET /livros?status=INVENTADO` contém um valor que a aplicação não reconhece. E `GET /livros/99` pede um livro que não existe no nosso conjunto. Percebe como são situações diferentes?

Para este exercício, você pode usar 200 na consulta válida, 400 no status desconhecido e 404 no identificador ausente. São decisões do contrato proposto, não uma lista completa de regras para qualquer API. O importante é o cliente conseguir distinguir as situações e seus testes conferirem essa diferença.

O [guia oficial de serviço REST do Spring](https://spring.io/guides/gs/rest-service/) apresenta uma requisição GET, um parâmetro e a resposta JSON. Reproduza o guia respeitando os requisitos da versão escolhida, depois acompanhe como a entrada chega ao método. Ao adaptar o projeto, explique o papel das anotações utilizadas em vez de copiá-las por semelhança visual.

## O que estudar de SQL antes de usar persistência

Em um banco local de treino, represente identificador e status em uma tabela. Pratique inserir registros, consultar com filtro, atualizar um registro pelo identificador e conferir o resultado. Revise a condição de uma atualização antes de executá-la: um filtro errado pode atingir registros que você não queria alterar.

O [tutorial de SQL do PostgreSQL](https://www.postgresql.org/docs/current/tutorial-sql.html) organiza criação de tabelas, inserção, consultas e atualizações. Você não precisa começar por otimização ou consultas complexas. Precisa observar quais dados existem e como uma operação os modifica.

Ao integrar o banco, reinicie a aplicação e consulte os livros novamente. Esse experimento distingue dados persistidos de uma coleção recriada a cada execução. Se usar uma camada de mapeamento objeto-relacional, continue verificando o que chegou ao banco; conhecer a API de persistência não elimina a necessidade de entender os dados.

Quando uma operação passar a exigir alterações conjuntas, estude [transações](https://www.postgresql.org/docs/current/tutorial-transactions.html). Por exemplo, atualizar o status e registrar seu histórico pode exigir que as duas gravações sejam confirmadas juntas. Faça esse incremento depois de compreender uma gravação simples.

## Projeto incremental: do filtro em memória à API

### Etapa 1: selecionar livros em uma coleção

Prepare dados fictícios com livros em status diferentes. Implemente a seleção sem modificar os registros de origem. Verifique conjunto vazio, um resultado, vários resultados e ausência de correspondência. Compare os identificadores retornados com o conjunto esperado, sem depender de uma ordem que você ainda não definiu.

Antes de seguir, troque o status de um livro e diga quais IDs espera receber. Depois execute. Guarde esses casos: eles serão úteis quando a consulta passar por HTTP e pelo banco.

### Etapa 2: receber o filtro por HTTP

Exponha a operação com Spring Boot. Acompanhe o caminho: parâmetro recebido, conversão ou validação, chamada da regra e resposta. Um status inválido deve seguir o contrato definido anteriormente.

Quando algo vier errado, acompanhe a entrada até a resposta. O parâmetro chegou como você esperava? A seleção devolveu os livros certos? Isso ajuda a localizar a falha sem tratar o framework como uma caixa fechada.

### Etapa 3: persistir e repetir as consultas

Troque a coleção temporária por armazenamento no banco de estudo. Verifique o mesmo conjunto de casos e repita a consulta após reiniciar a aplicação. Desligue somente esse banco de teste para observar uma falha controlada. Registre como o erro aparece e como o cliente é informado, sem expor detalhes internos indevidos.

Aqui, tente reconhecer duas situações: a consulta funcionou e não encontrou livros; ou a aplicação nem conseguiu consultar o banco. Elas precisam ser tratadas de formas diferentes.

### Etapa 4: mudar o requisito sem refazer o tutorial

Acrescente um filtro por autor que possa ser combinado com o status. Para o exercício, os dois filtros presentes devem ser atendidos ao mesmo tempo. Quando um estiver ausente, só o outro restringe a busca.

| Caso | Evidência esperada |
| --- | --- |
| Apenas status | Resultado igual ao comportamento anterior. |
| Apenas autor | Livros daquele autor, independentemente do status. |
| Ambos | Somente a interseção dos dois conjuntos. |
| Filtros válidos sem correspondência | Lista vazia, sem erro de entrada. |
| Status inválido com autor válido | Erro de entrada; o segundo filtro não mascara o problema. |

Volte aos três livros. O filtro por Ana retorna 11 e 12. O filtro por `EM_LEITURA` retorna 11 e 13. Ao combinar os dois, sobra apenas o 11. Se aparecerem os três, provavelmente você juntou os resultados em vez de exigir que cada livro atendesse às duas condições.

Você concluiu esse incremento quando consegue explicar o que mudou e repetir os casos antigos sem quebrá-los. Ainda faltam decisões de acesso, concorrência, volume de dados e operação para tratar a API como uma aplicação de produção.

O filtro combinado pode começar assim, sem Spring. O `record` representa os dados do exercício; cada `filter` mantém somente quem atende à condição. Salve como `CatalogoDemo.java` e execute `java CatalogoDemo.java` com Java 21:

```java
import java.util.List;

public class CatalogoDemo {
    enum Status { NAO_INICIADO, EM_LEITURA, CONCLUIDO }
    record Livro(int id, String autor, Status status) {}

    static List<Integer> filtrar(List<Livro> livros, String autor,
                                 Status status) {
        return livros.stream()
            .filter(livro -> livro.autor().equals(autor))
            .filter(livro -> livro.status() == status)
            .map(Livro::id)
            .toList();
    }

    public static void main(String[] args) {
        var livros = List.of(
            new Livro(11, "Ana", Status.EM_LEITURA),
            new Livro(12, "Ana", Status.CONCLUIDO),
            new Livro(13, "Rui", Status.EM_LEITURA)
        );
        var resultado = filtrar(livros, "Ana", Status.EM_LEITURA);
        if (!resultado.equals(List.of(11))) throw new AssertionError();
        if (!filtrar(livros, "Lia", Status.EM_LEITURA).isEmpty()) {
            throw new AssertionError();
        }
        System.out.println(resultado); // [11]
    }
}
```

O resultado é `[11]`: o livro 12 tem a autora procurada, mas outro status; o 13 tem o status procurado, mas outro autor. A consulta por Lia retorna uma lista vazia. Nenhum registro foi alterado. Os dois casos foram executados com OpenJDK 21.0.2. Antes de transportar essa regra para um controller, acrescente um teste com entrada vazia e outro com dois livros que atendam às condições. Este recorte exige os dois filtros; tratar parâmetros opcionais será uma alteração posterior.

## Como retomar depois de um tempo sem estudar

Abra um projeto que você consegue executar e escolha um comportamento conhecido. Rode, explique e altere esse comportamento. Evite decidir que precisa recomeçar tudo antes de descobrir o que realmente esqueceu.

Antes de parar, deixe um registro curto: “O filtro por status funciona. Ao combinar com autor, recebo 11, 12 e 13; esperava só 11. Na próxima sessão, vou conferir a condição do filtro”. Esse bilhete é mais útil na retomada do que “continuar estudando Java”. Se ainda ficar preso, leve o caso e o resultado esperado para uma revisão humana.

## Erros que prolongam a dependência de tutoriais

* **Adicionar HTTP, banco e várias dependências no mesmo passo:** mantenha um comportamento verificável entre incrementos.
* **Copiar anotações sem observar o efeito:** siga uma requisição e confira qual parte do fluxo depende delas.
* **Tratar lista vazia como falha técnica:** diferencie contrato de consulta, entrada inválida e infraestrutura indisponível.
* **Só testar depois de terminar:** preserve os casos do projeto em memória e repita-os após cada mudança.
* **Trocar de projeto a cada dificuldade:** reduza a tarefa para localizar a lacuna antes de abandonar o contexto.

## Perguntas sobre a ordem dos estudos

### Preciso dominar Java antes de começar Spring?

Não existe um ponto único de domínio completo. Comece quando conseguir acompanhar uma pequena regra e suas entradas e saídas. Volte ao Java quando o obstáculo for objetos, tipos, coleções ou exceções. Avançar e revisar podem fazer parte do mesmo projeto.

### Posso aprender SQL junto com Spring Boot?

Sim. Primeiro observe uma operação diretamente no banco de treino; depois compare com a operação feita pela aplicação. Assim fica mais fácil separar um problema da consulta de um problema da integração.

### Preciso estudar microsserviços agora?

Este roteiro não depende deles. Uma aplicação pequena já permite praticar entrada, regra, persistência e testes. Estude distribuição quando houver uma pergunta concreta sobre comunicação, falhas ou responsabilidades entre serviços, sem usar a quantidade de serviços como medida de aprendizado.

## Checklist e próximo passo com a formação

* Executo o projeto com instruções que registrei, incluindo versões e ferramenta de build.
* Explico o caminho da entrada até a resposta.
* Localizo uma falha e formulo uma hipótese verificável.
* Mudo o filtro e preservo o comportamento anterior.
* Distingo memória, persistência e falha de conexão.
* Sei indicar uma dúvida específica para revisão.

As referências oficiais citadas foram consultadas em 22/10/2026. Registre as versões usadas ao implementar o exercício.

Na [visão de trilhas](https://dev.buildrun.com.br/blog/trilhas-de-estudo/), você encontra outra forma de conectar programação, backend e operação. Se preferir estudar com a Build & Run, consulte os [conteúdos da formação](https://dev.buildrun.com.br/blog/formacao-buildrun/) e compare com as dificuldades que encontrou no catálogo.

## Continue o estudo

Ao usar um assistente durante o roteiro, consulte o [ciclo de estudo com IA sem pular fundamentos](https://dev.buildrun.com.br/blog/java-junior-ia-sem-pular-fundamentos/) para verificar se consegue explicar e modificar a solução.

## Para levar à prática

Comece pela regra em memória e acrescente HTTP e persistência quando conseguir explicar a etapa anterior. No catálogo, acompanhar quais livros entram no filtro dá uma pergunta concreta para estudar, testar e levar ao Spring.