REST - Uma breve introdução
Tags: beginners, node, architecture, braziliandevs
Published: 2022-03-28 21:09:59

## Tabela de Conteúdo
- [Rest](#rest)
- [Restrições REST](#restrições-rest)
  - [Interfaces uniformes](#interface-uniforme)
  - [Cliente-servidor](#cliente-servidor)
  - [Stateless](#stateless)
  - [Cacheable](#cacheable)
  - [Layered System](#layered-System)
  - [Code on Demand](#code-on-demand)

## Rest

### O que é?

É um estilo de arquitetura de Software que possui um conjunto de restrições para a criação de APIs, sendo controlado pelo W3C. Em palavras mais simples, é um conjunto de regras que nossa aplicação deve seguir no momento de se comunicar com clientes, sejam eles Browsers ou outras APIs.

___

## Restrições REST

### Interface uniforme

#### O que é?

É a padronização sistemática e constante da interface de comunicação entre cliente e servidor. Essa interface é composta pelo endpoint, tipo de retorno e verbos HTTP.

#### Endpoint

O endpoint deve identificar o recurso a ser acessado/alterado, de forma que o recurso fique __explícito__ na URL.

#### Tipo de retorno

Os retornos devem ser consistentes, ou seja, se enviarmos um requisição ao endpoint `/products` e retornarmos um Array contendo os produtos, o mesmo deve ser feito ao enviarmos uma requisição ao endpoint `/categories` _(Array contendo as categorias)_.

Devemos construir os retornos padronizados para que seja possível _"deduzir"_ o comportamento dos demais endpoints, sem a necessidade de _"tentativa e erro"_.

#### Verbos HTTP

Toda a ação que vamos realizar deve ser identificada através de um verbo HTTP, sendo os principais POST, GET, PUT e DELETE. Reforçando que __os verbos devem disparar ações correspondentes a seus significados__, logo uma requisição GET deve apenas retornar algum recurso, sem alterar/deletar nada.

---

### Cliente servidor

#### O que é?

É a desacoplação entre Cliente e Servidor, em outras palavras, nossa API deve poder ser consumida a partir de qualquer cliente, seja ele uma aplicação mobile, web, tv ou até mesmo Arduíno.

O princípio básico é a separação de responsabilidades, o servidor deve se preocupar somente com armazenamento e acesso aos dados, cache, log e outras funcionalidades essenciais para o bom funcionamento da aplicação,

---

### Stateless

#### O que é?

O princípio Stateless significa que nossa aplicação não deve guardar informações em seu contexto. <small>_Uma variável que guarda o login, por exemplo._</small>

Dessa forma, __todas as requisições enviadas ao servidor devem ser autossuficientes__, ou seja, devem possuir todas as informações necessárias para a realização da requisição, já que a API não irá armazenar nada.

Um exemplo fácil de entender é o de login:
> Assim que uma pessoa usuária realiza o login em nosso site, iremos gerar um token de autenticação para ela, a partir daí, todas as requisições que essa pessoa for realizar, será preciso enviar o token de autenticação junto, pois nossa API _"não se lembrará"_ da pessoa.

---

### Cacheable

#### O que é?

Nossa API deve ser capaz de informar ao cliente se determinada resposta pode ser _cacheada_, e se puder, por quanto tempo deverá ser _cacheada_.

Nesse caso estamos nos referindo ao cache no lado do Cliente, logo a função de nossa API é apenas informar as regras que precisam ser seguidas.

---

### Layered System

#### O que é?

Diferente da arquitetura MSC, o princípio do __Layered System não tem relação com a organização do código__, mas sim com a abstração da resposta da API. Isso significa que o Cliente não precisa saber o que foi feito para a resposta ser montada, apenas que recebeu uma resposta.

---

### Code on Demand

### O que é?

É a possibilidade do servidor enviar código ao cliente, esse código pode ser JavaScript, Python, C, C# ou de qualquer outra linguagem que faça sentido.

__Esse princípio é opcional na construção de uma API REST__, sendo assim podemos ter uma aplicação que não envia código ao servidor e continua sendo RESTful.