Controllers e views

Um controller do Spring MVC se parece tanto com uma classe Java comum que é fácil esquecer a quantidade de trabalho que o framework faz ao redor dele. Um método declara @PathVariable Long id, @RequestParam int page, Model model e recebe três valores prontos para uso, extraídos de três lugares diferentes da requisição, convertidos para o tipo certo, validados. Nenhuma dessas conversões aparece no seu código.

Essa economia tem um preço: quando algo dá errado, a causa muitas vezes é invisível, porque está em uma convenção que você não conhecia. Uma variável de caminho que chega vazia porque o nome não corresponde. Um parâmetro ausente que dispara um 400 quando você o queria opcional. Um redirecionamento após um formulário que perde a mensagem de confirmação. Um objeto adicionado ao modelo, mas que não é encontrado no template.

Todas essas situações têm a mesma origem: o contrato entre o seu método e o framework se baseia em nomes e tipos, não em código explícito. Entender esse contrato é entender onde olhar quando ele não é respeitado.

Esta lição detalha esse contrato nos dois sentidos — o que o método pode receber, o que ele pode retornar — e depois passa para a view Thymeleaf: iteração, fragmentos reutilizáveis e o mecanismo dos flash attributes, que resolve de uma vez por todas o problema da mensagem de confirmação após o redirecionamento.