CallFé Dev 007 – API: o que é? Qual a diferença entre REST e RESTful?5 min de leitura

Fala galera! Hoje nós vamos falar sobre uma das arquiteturas mais utilizadas na web: REST. Também vamos falar sobre a diferença entre REST e RESTful! Você sabe diferenciar? Vamos entender qual é a diferença entres esses termos! Então, vem comigo para mais este episódio do podcast cheio de informações bacanas para você!

Ouça o episódio aqui

Este podcast está dividido em quatro partes, então caso queira ouvir por parte segue os minutos:

• Parte 1 (API: o que é?): 3m15s até 18m40s
• Parte 2 (REST): 18m40s até 37m00s
• Parte 3 (RESTful): 37m00s até 46m00s
• Parte 4 (Boas práticas): 46m00s até o fim

Links relacionados

Meu LinkedIn: https://www.linkedin.com/in/fabio-almeida100/
HTTP Overview
Definição de URI
REST – dissertação Dr. Roy Fielding
HATEOAS
Richardson Maturity Model
Críticas e sugestões: contato@criarprogramas.com

API endpoint vs Resources

Na prática, você vai ouvir comumente que endpoint e resources são sinônimos, porém existe uma diferença:

• O termo endpoint significa a URL usada para fazer uma solicitação.
• Já o termo (resource) recurso concentra-se no conjunto de dados que é retornado por uma solicitação.

Veja abaixo um diagrama:

Na tabela abaixo, talvez fique mais claro a divisão dos conceitos:

Porém, reforço que muito frequentemente você irá ouvir esses conceitos como sinônimo.

Você pode ler um pouco mais sobre essa discussão, clicando aqui.

URI – Uniform Resource Identifier

Identificador de Recursos Universal é o identificador de um recurso específico na Web. Pode ser uma imagem, uma página, um endpoint de uma API… A URI é extremamente útil, pois na web cada recurso precisa de um identificado único, certo?

Exemplo de URI:

• https://criarprogramas.com/category/podcast-callfe-dev/

A URI é composto pela soma dos fragmentos de um endereço web, veja:

Protocolo (https://) a localização do recurso (URL – criarprogramas.com) e o nome do recurso (URN – /category/podcast-callfe-dev/) para que você acesse as coisas na Web.

Por que API REST deve ser stateless?

Essa restrição é muito importante, pois além do fato de manter sua API leve e consumindo menos recurso, você também vai evitar:

• problemas de escalabilidade: se você não armazena estado, você consegue escalar de forma horizontal muito mais facilmente, pois não vai precisar de compartilhar esse estado entre as novas instâncias
• possíveis erros: você evita erros inesperados e possíveis colisões nas requisições
• problemas com uma possível migração de servidor no futuro

Os HTTP statuscode mais frequentes em API REST

Sempre que um servidor recebe uma solicitação HTTP ele irá retornar uma resposta. No HTTP estas respostas estão padronizadas através dos statuscode. Nas API REST os status mais comuns são:

• 2xx – Status de sucesso
• 4xx – Erro no Cliente
• 5xx – Erro no server

2xx – Status sucesso

200 [Ok] – Representa sucesso na requisição. Resposta padrão para GET, quando há resultados.
201 [Created] – Indica que um recurso foi criado. Utilize para a resposta de um POST.
204 [No Content] – Representa que a request foi processada com sucesso, mas não há conteúdo para ser retornado. Muito utilizado nas requisições feitas com os verbos PUT, PATCH e DELETE.

4xx – Erro no Cliente

• 400 [Bad Request] – A solicitação não foi processada, pois a API não conseguiu receber a requisição de forma correta.
• 401 [Unauthorized] – O cliente não está autenticado e não tem autorização para acessar o recurso.
• 404 [Not Found] – O famoso 404 não encontrado: informa que o recurso requisitado ao servidor não foi encontrado.

5xx – Erro no server

• 500 [Internal Server Error] – indica que houve uma falha no servidor e não conseguiu processar a requisição.
• 503 [Service Unavailable] – informa que o serviço está indisponível.
• 504 [Gateway Timeout] – o servidor não conseguiu responder a requisição no tempo máximo permitido.

As características de uma API REST

A tabela abaixo resume bem o que é o REST (sem considerar as restrições):

Modelo de maturidade de Richardson

Abaixo um diagrama para mostrar como funciona o modelo de Richardson:

• no nível 0 você está, basicamente, apenas usando o protocolo HTTP
• no nível 1 sua API já está dividida em recursos e usando endpoints segmentados, porém não usa os verbos de forma correta. Nesse ponto, normalmente a sua API só usa o GET e o POST;
• no nível 2 introduz um conjunto padrão de verbos para lidar com as requisições de uma forma mais legível (GET, POST, PUT, DELETE)
• no nível 3 será introduzido a descoberta e navegação entre os recursos, fornecendo uma maneira de fazer um protocolo auto-documentado, através do uso de HATEOAS.