Spring Boot: desenvolvendo uma API RESTful

Fundamentos de API REST com Spring Boot - Apresentação

Dando boas-vindas e fazendo autodescrição

Boas-vindas, pessoa estudante, ao curso de Spring Boot, construindo sua primeira API. Eu sou Damiana Costa e farei minha autodescrição.

Audiodescrição: Sou uma mulher negra, com cabelo cacheado, usando um brinco de argola e uma camiseta laranja. Estou no estúdio da Alura.

Sou engenheira principal no Itaú e especialista em arquitetura e back-end (camada de servidor).

Apresentando os temas do curso

Vamos apresentar uma visão geral do conteúdo que veremos no curso. Vamos discutir API REST, sua importância e como criamos APIs modernas. Também vamos apresentar a ferramenta que utilizaremos no curso, que é o Spring Boot.

Vamos tratar de persistência de dados com PostgreSQL e JPA. Abordaremos validações e DTOs, destacando a importância desses recursos para a entrada e a saída de dados.

Detalhando ferramentas e encerrando a introdução

Também abordaremos Swagger, uma forma de documentar a API, e Docker, ferramenta que utilizaremos para conteinerizar nosso serviço. Com apoio de IA, utilizaremos Cloud Code para auxiliar o desenvolvimento.

Com tudo isso, vamos compor nosso serviço Pomodoro API para integrarmos com o front-end (camada de interface). Espero que haja entusiasmo para a jornada de aprendizado que temos pela frente. Nos vemos na próxima aula. Bons estudos!

Fundamentos de API REST com Spring Boot - O que é back-end?

Contextualizando o back-end na aplicação Pomodoro

Antes de começarmos a desenvolver nossa aplicação, precisamos entender o que é o back-end (lógica e serviços no servidor).

Quando falamos de uma aplicação Pomodoro, na qual trabalharemos foco e concentração, teremos alguns minutos de foco e alguns minutos de concentração. Para desenvolver essa aplicação, precisamos compreender o back-end (lógica e serviços no servidor), que será o núcleo do nosso curso aqui. Quem guarda as tarefas? Quem sabe se uma tarefa foi completada ou se está pendente? Onde ficam essas regras? Como os dados continuam existindo depois que fecharmos a aplicação? Onde organizamos tudo isso? O front-end (camada de interface do usuário) exibe os dados. Vamos criar a aplicação Pomodoro com um front-end (camada de interface do usuário) bem estruturado, mas onde esses dados são armazenados? Quem realiza esse processamento? É isso que veremos aqui.

Definindo as responsabilidades do back-end

O que é o back-end (lógica e serviços no servidor), propriamente dito? O back-end (lógica e serviços no servidor) é responsável pelo armazenamento e pela recuperação das informações. Aqui trabalharemos com banco de dados, não com memória volátil.

Dentro do back-end (lógica e serviços no servidor), também temos as regras de negócio. Aqui processaremos e validaremos as informações. Por exemplo, existe uma tarefa que está completa ou pendente. A partir disso, podemos tomar outra ação, como enviar um e-mail ou configurar um alerta. Por meio das regras de negócio, podemos executar outras tarefas automatizadas.

Temos ainda a API (interface de programação de aplicações), um ponto muito importante dentro do back-end (lógica e serviços no servidor). A responsabilidade de uma API (interface de programação de aplicações) é expor os dados para que um front-end (camada de interface do usuário), outro back-end (lógica e serviços no servidor) ou qualquer outro sistema possa utilizá-los.

Há também a parte de segurança. Autenticação e autorização são responsabilidades do back-end (lógica e serviços no servidor), não do front-end (camada de interface do usuário). Dentro do back-end (lógica e serviços no servidor), reunimos armazenamento, regras de negócio, API (interface de programação de aplicações) e segurança. Por isso, é essencial compreendermos as responsabilidades do back-end (lógica e serviços no servidor), pois ele é uma parte central de um sistema, a camada por trás do front-end (camada de interface do usuário) que dá dinamismo para que as coisas aconteçam.

Contrastando front-end e back-end

O front-end (camada de interface do usuário) envolve arquivos como HTML (linguagem de marcação de hipertexto), CSS (folhas de estilo em cascata), JavaScript (linguagem de programação JavaScript) e o próprio React (biblioteca para construção de interfaces). É tudo aquilo que a pessoa usuária vê e com o que pode interagir.

O back-end (lógica e serviços no servidor) corresponde a tudo que é executado em um servidor remoto — remoto porque não está com a pessoa usuária. A pessoa usuária acessa um serviço, por exemplo, que está na nuvem. Existem várias linguagens de programação para trabalhar com back-end (lógica e serviços no servidor). Neste curso, trabalharemos com Java, mas poderíamos utilizar outras linguagens, como C++, Go ou Node.js. Aqui escolhemos trabalhar com Java e criaremos nosso back-end (lógica e serviços no servidor) usando conceitos do Spring Boot (framework do ecossistema Spring), além de bancos de dados.

Quando falamos de back-end (lógica e serviços no servidor), referimo-nos ao que a pessoa usuária não vê: tudo que acontece por trás, o que dá vida ao front-end (camada de interface do usuário).

Explicando onde o back-end é executado

Onde o back-end (lógica e serviços no servidor) é executado? Temos três pontos importantes para compreender:

• Servidores físicos: um servidor físico é a máquina que permanece ligada 24 horas nos centros de dados. Hoje, essa prática é menos comum. Chamamos esse modelo de servidores on-premises (instalado localmente). Ele ainda é utilizado, especialmente em bancos. Antigamente, os bancos trabalhavam com esses servidores de forma física; ao entrar em uma instituição, por exemplo, havia uma sala grande com vários computadores, que eram os servidores dos serviços bancários. Com o passar dos anos, esse cenário se modernizou.

• Nuvem: temos provedores como a AWS (Amazon Web Services), a Google Cloud Platform (GCP) (plataforma de nuvem da Google) e a Microsoft Azure (plataforma de nuvem da Microsoft). São servidores sob demanda, isto é, contratamos um serviço e podemos fazer deploy (publicação) em qualquer uma dessas nuvens, pagando apenas pelo que queremos usar. Se quisermos utilizar somente o servidor, pagamos por ele; se quisermos somente o banco de dados, pagamos por ele; e assim por diante.

• Execução local: há a forma local de executar nosso back-end (lógica e serviços no servidor), que também utilizaremos no curso. Ao longo do desenvolvimento, executaremos o projeto em nossa máquina.

Definindo a API como contrato e exemplificando

Temos três formas de executar o desenvolvimento do nosso back-end (camada de servidor) aqui. Ao falar de back-end, há um ponto extremamente importante: nossa API (Interface de Programação de Aplicações). A API é um contrato entre o front-end (camada de interface) e o back-end. É a forma de definir o que queremos e o que receberemos como resposta. Esse é um conceito central para o desenvolvimento moderno, sobretudo na web.

No mundo real, há diversos exemplos. Na Netflix, quando acessamos o aplicativo, aparecem recomendações — séries e filmes — na nossa tela do front-end. Isso ocorre por meio de uma API. No contexto do Spotify, acontece o mesmo: as playlists que temos, as recomendações e aquela banda de que gostamos aparecem para nós quando acessamos o aplicativo por meio de uma API. O mesmo ocorre no Uber: quando fazemos uma viagem, como a pessoa motorista aparece no nosso aplicativo e como nós aparecemos no aplicativo da pessoa motorista, na posição de pessoa passageira, tudo é viabilizado pelo back-end por meio de APIs.

A ideia é que o back-end se conecte com o front-end. O front-end não possui a lógica necessária para realizar tudo o que uma API faz; por isso, é importante separar os contextos. Além disso, precisamos armazenar certas informações e dados, e utilizamos um banco de dados para isso. O back-end processa informações como login, dados da pessoa usuária, cartões (como cartão de crédito) e informações que manipulamos, por exemplo, a localidade para a qual queremos ir. Tudo isso é armazenado em um banco de dados.

Ilustrando com a analogia do restaurante e reforçando boas práticas

Fazendo uma analogia com o que temos no mundo real, imaginemos um restaurante. Nós, como pessoas clientes, fazemos um pedido — por exemplo, um prato de massa. Não sabemos como a comida é preparada, mas solicitamos ao atendente o prato desejado. O atendente recebe o pedido e o leva à cozinha. Na analogia, quem é o atendente no contexto do back-end? A API. A API recebe o pedido feito pela pessoa cliente (isto é, pelo front-end) e o leva ao back-end. A cozinha realiza o processamento, produz o prato de massa e o atendente o traz de volta. É exatamente assim que o back-end funciona: o front-end faz a solicitação junto com a pessoa cliente; existe uma API para intermediar o caminho — muitas vezes chamada de middleware (camada intermediária) — e essa API leva a solicitação ao back-end. O back-end processa o pedido feito pelo front-end, devolve para a API e a API retorna para a pessoa cliente.

Um ponto importante: a pessoa cliente — o front-end — nunca se comunica diretamente com a cozinha — o back-end. Se virmos isso em algum exemplo, trata-se de uma má prática de desenvolvimento. O front-end, por si só, não deve conter lógica de negócio; tudo isso deve estar no back-end. A comunicação deve sempre passar pela API, que organiza e orquestra a comunicação entre front-end e back-end.

Construindo a arquitetura da aplicação Pomodoro

Olhando para a arquitetura da aplicação, o que vamos desenvolver no nosso Pomodoro? O front-end nós já temos: o temporizador, a lista de tarefas e uma UI (Interface do Usuário) completa. Precisamos desenvolver mais duas camadas. Usaremos Spring Boot para criar uma API. Trabalharemos com REST (Transferência de Estado Representacional), com endpoints (rotas) e com as regras de negócio, pois, novamente, não podemos ter regras de negócio no front-end. Iremos também para uma terceira camada, a camada de banco de dados. Precisamos persistir, por exemplo, as tarefas e se foram concluídas ou não. Mais adiante, adicionaremos dados da pessoa usuária e autenticação. Tudo isso deve estar na camada de back-end. Teremos uma camada de banco de dados para armazenar e persistir os dados.

Essa será exatamente a arquitetura que construiremos ao longo do curso. Na próxima aula, falaremos sobre como a web se comunica por meio do back-end.

Fundamentos de API REST com Spring Boot - Como a web se comunica

Revisitando o modelo cliente-servidor

No vídeo anterior, falamos sobre o que é o back-end (lógica do servidor), mas o back-end (lógica do servidor) por si só não é suficiente. Vamos discutir como a web (rede) se comunica.

Provavelmente já sabemos como funciona o modelo cliente-servidor. A ideia aqui é revisitar alguns conceitos. Observando o ciclo de comunicação, como vai funcionar hoje o cliente-servidor? Como já funciona no contexto de desenvolvimento?

Temos a pessoa usuária, que vai interagir com nosso front-end (interface do cliente). O front-end (interface do cliente) envia essa informação ao servidor. Pensemos que a pessoa usuária está, por exemplo, realizando um cadastro. O front-end (interface do cliente) coleta esses dados e os envia ao back-end (lógica do servidor). O back-end (lógica do servidor) recebe os dados informados, processa-os e, por meio de JSON, devolve a resposta. Assim, por meio de um arquivo de resposta, a pessoa usuária recebe essa informação.

Para que isso ocorra, utilizamos HTTP. Relembrando, existem alguns métodos muito importantes; trouxemos quatro aqui para revisar.

Explicando os métodos HTTP essenciais

O método GET é responsável por buscar dados e trazer informações. Não altera nada no servidor; é idempotente e apenas retorna o que foi solicitado. Pode trazer todos os dados que estão no banco de dados ou apenas um registro, caso seja passado um ID.

O método POST é responsável por criar um novo recurso. Aqui entendemos, por exemplo, realizar um cadastro, efetuar uma compra — tudo que for novo e que esteja sendo criado. Usamos POST para criar um recurso no servidor.

O método PUT é responsável por atualizar um recurso. Imagine que a pessoa usuária se cadastrou e digitou o nome incorretamente. Não precisamos criar um novo cadastro; utilizamos PUT para atualizar esse recurso — por exemplo, corrigir o nome da pessoa usuária.

Por fim, temos o método DELETE de HTTP, responsável por remover um recurso no servidor. Talvez a pessoa usuária não queira mais acessar o sistema e opte por excluir a conta. Nessa remoção, apagamos essa informação.

Existem outros métodos HTTP, mas aqui destacamos os quatro mais importantes dentro do contexto com o qual vamos trabalhar no curso.

Apresentando os endpoints da aplicação Pomodoro

Na nossa aplicação Pomodoro, nós temos alguns endpoints (rotas) que estamos exemplificando aqui e que vamos criar ao longo do curso e do nosso desenvolvimento.

Temos o endpoint (rota) /tasks, do tipo GET (buscar). Esse endpoint (rota) será responsável por trazer todas as tarefas que nós vamos criar no Pomodoro.

Para visualizar essa rota de listagem de tarefas, faremos a chamada assim:

GET /tasks

Essa chamada retorna a lista completa de tarefas cadastradas.

Criando tarefas com POST

O próximo endpoint (rota) é /tasks, do tipo POST (criar). Esse endpoint (rota) será responsável por criar novas tarefas. Por exemplo, nós criaremos uma tarefa para ler uma aula específica de Java e uma tarefa para estudar sobre arquitetura. Sempre que criarmos uma nova tarefa, é essa requisição POST (criar) para esse endpoint (rota) que será responsável por inseri-la na base de dados.

Na prática, a criação de uma nova tarefa é feita assim:

POST /tasks

Essa requisição insere um novo recurso de tarefa no servidor.

Atualizando tarefas com PUT

O mesmo ocorre com o método PUT (atualizar). No PUT (atualizar), nós temos o endpoint (rota) /tasks/1, em que o 1 simboliza o ID do recurso que queremos alterar. Lembrando que o método PUT (atualizar) é responsável por fazer uma modificação. Exemplo: se concluirmos a tarefa de arquitetura que estávamos lendo, em vez de deixá-la como true, nós vamos marcá-la como finalizada. Aqui, o PUT (atualizar) é o responsável por fazer essa alteração.

A atualização de uma tarefa específica (pelo seu ID) fica assim:

PUT /tasks/1

Note que incluímos o identificador do recurso na rota para especificar qual tarefa será atualizada.

Excluindo tarefas com DELETE

Em seguida, temos o último método, DELETE (excluir). Nós utilizamos endpoints (rotas) como, por exemplo, /tasks/1. Esse endpoint (rota) é responsável por excluir um recurso. Se criarmos uma tarefa e precisarmos apagá-la porque não vamos mais realizá-la, usamos o método DELETE (excluir) com o endpoint (rota) /tasks/1, em que o 1 simboliza qual recurso queremos remover. Podemos excluir o ID 1, o ID 2, o ID 3 e assim sucessivamente. Indicamos isso na nomenclatura do nosso endpoint (rota).

A remoção de uma tarefa específica é representada por:

DELETE /tasks/1

Decompondo a URL do recurso

Quanto à composição da URL (endereço), ela ficará exatamente assim: localhost:8080/tasks/1. Se usarmos essa URL (endereço) com o método GET (buscar), ela trará a tarefa com ID 1. Se a tarefa com ID 1 for, por exemplo, estudar sobre um método em Java, então essa URL (endereço) retornará essa tarefa que nós criamos. Mantemos a rota segmentada para sabermos com qual recurso estamos trabalhando.

Podemos decompor essa URL em seus componentes da seguinte forma:

URL = Endereço do recurso
http://localhost:8080/tasks/1
Host: localhost:8080
Path: /tasks/1

Contextualizando o recurso /tasks e o ambiente

Dentro deste curso, nós trabalharemos com um único recurso específico: /tasks. Depois da barra, podemos ter vários IDs. O localhost indica onde está sendo executado o nosso back-end (camada de servidor). Como comentamos no vídeo anterior, nós trabalharemos de forma local. Porém, quando fizermos o deploy (implantação) na nuvem, por exemplo, na AWS (Amazon Web Services), o host (servidor) será diferente.

Este é o contexto de como vão funcionar os nossos endpoints (rotas) da API (Interface de Programação de Aplicações) Pomodoro.

Sobre o curso Spring Boot: desenvolvendo uma API RESTful

O curso Spring Boot: desenvolvendo uma API RESTful possui 241 minutos de vídeos, em um total de 67 atividades. Gostou? Conheça nossos outros cursos de Java em Back-end, ou leia nossos artigos de Back-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos de API REST com Spring Boot
• REST e endpoints
• Controllers e Request/Response
• CRUD com Spring Data JPA
• Persistência de dados com PostgreSQL e DBeaver
• DTOs e validações em Spring Boot
• Documentação de APIs com Swagger
• Containerizando a API com Docker