Nos projetos anteriores, o Principal.java decidia sozinho o que fazer: chamava o DAO, imprimia o resultado no console e terminava.

Uma aplicação web não executa uma sequência de passos e encerra. Ela sobe um servidor, fica escutando numa porta do computador e responde a cada pedido que chega.

Para cliente e servidor se entenderem, os dois seguem as mesmas regras de comunicação. Na web, essas regras se chamam HTTP (Hypertext Transfer Protocol).

GET/series pede a lista e não precisa de corpo. Já um cadastro leva no corpo os dados da série nova.

O código de status é a primeira coisa que o cliente lê: antes de olhar o corpo, ele já sabe se deu certo ou não.

Qualquer sistema que guarda dados precisa fazer quatro operações básicas sobre eles. A sigla CRUD reúne as iniciais dessas operações em inglês:

Já fizemos essas quatro operações duas vezes, com nomes diferentes: no SQL, em Banco de Dados, e no DAO com JPA, no encontro 5.

O verbo é a parte da requisição que diz o que o cliente quer fazer com o recurso. Os quatro mais usados são:

Cada operação do CRUD tem um verbo HTTP correspondente.

Quando um cliente quiser cadastrar uma série, ele manda um POST; quando quiser ver as séries, manda um GET. O verbo diz a intenção, e a nossa aplicação escolhe o código que atende essa intenção.

Uma rota é a combinação de um verbo com um caminho, ligada ao método Java que deve responder. O mesmo caminho aparece em rotas diferentes, porque o verbo muda a intenção.

Juntando tudo, cada rota termina num método do DAO que já sabemos escrever:

Para uma aplicação Java responder requisições HTTP, alguém precisa:

O Spring é um framework Java: um conjunto de bibliotecas que já resolve a infraestrutura de uma aplicação, para que nós escrevamos só a parte que é do nosso sistema.

Por exemplo: nós escrevemos o método que lista as séries, e o Spring cuida de receber a requisição, chamar esse método e devolver a resposta.

O Spring é formado por vários projetos. Os que usamos hoje são:

O Spring Boot traz o servidor web embutido (o Tomcat), escolhe versões compatíveis das bibliotecas e configura quase tudo sozinho a partir do que encontra no projeto.

Executamos a SeriesApplication antes de configurar qualquer coisa. A aplicação não sobe, e o console mostra:

O trecho createDatabaseIfNotExist=true pede ao MySQL que crie o banco series se ele ainda não existir.

Executando de novo, duas mensagens mostram que deu certo:

Cada método agora tem só a operação: persist, find, merge, remove e a consulta JPQL, os mesmos do encontro 5.

Cada método agora tem só a operação: persist, find, merge, remove e a consulta JPQL, os mesmos do encontro 5.

Cada método agora tem só a operação: persist, find, merge, remove e a consulta JPQL, os mesmos do encontro 5.

O controller é a classe que recebe as requisições HTTP. Cada método dele responde a uma rota: recebe o pedido, chama o DAO e devolve a resposta.

Com a aplicação rodando, abrimos no navegador:

O navegador só envia GET quando digitamos um endereço. Para enviar POST, PUT e DELETE, precisamos de um cliente HTTP: um programa em que escolhemos o verbo, escrevemos o caminho e montamos o corpo.

PUT/series/{id} recebe o id pelo caminho e os dados novos pelo corpo.

PUT/series/{id} recebe o id pelo caminho e os dados novos pelo corpo.

Uma loja de games usados quer um catálogo dos jogos à venda. Cada jogo tem nome, desenvolvedora, ano de lançamento e plataforma. No mesmo projeto series: