Introdução

Atualmente, estou trabalhando no meu primeiro projeto full-stack que pretendo compartilhar em breve com vocês, e, portanto, estou aprendendo sobre APIs RESTful, e já estou com 70% do projeto pronto, entretanto, até agora só tive uma definição bem simplificada de REST, então é possível que eu nem mesmo tenha feito uma API Rest (você vai entender o porquê depois), mas tudo é um aprendizado, e é preciso balancear a prática com a teoria.

Por isso, decidi criar este artigo para eu poder aprender com ele o que é REST, da maneira mais simples possível, e, ao mesmo tempo, gerar conteúdo aqui no tabnews. Espero que esteja útil, e como sou um estudante novo nisso, aceito todas as correções possíveis.

O que é REST?

Definição formal.

Representational State Transfer (REST) é um estilo de arquitetura de sistemas de hipermídia que define um conjunto de restrições a serem aplicadas, sendo elas: client-server, stateless, cache, uniform interface, layered system e code on demand.

Vamos quebrar esta definição formal (talvez não tão formal assim, pois foi elaborada por mim): REST é um estilo de arquitetura, estilo é uma forma de se fazer alguma coisa, enquanto arquitetura é o planejamento para a construção de algo, ou seja, REST é um estilo de planejamento para a construção de algo.

Continuando nosso raciocínio, REST é um estilo de planejamento para a construção de sistemas de hipermídia, hipermídia são várias formas de mídia, tal como imagens, vídeos, textos etc. Estes sistemas de hipermídia possuem um conjunto de restrições, o que seria esse conjunto? Esse conjunto refere-se a limitações a serem usadas para a criação de serviços-web específicos, denominados Web services RESTful, estes são os serviços-web que usam o estilo de arquitetura RESTful.

Então, vamos continuar nossa definição super simplificada: REST é um estilo de planejamento para a construção de sistemas que usam fotos, vídeos, textos etc, que possue um conjunto de restrições para criar serviços-web que utilizam do estilo RESTful.

O que é uma API?

Agora que entendemos o que é o estilo de arquitetura REST, vamos relembrar o que é uma API. API é acrônimo para Application Programming Interface, ou Interface de Programação de Aplicações. Uma API é um conjunto de serviços que foram implementados em um programa de computador que são disponibilizados para outros programas de forma simplificada, sem envolver os detalhes da implementação do código.

Como o foco deste artigo é em REST, e não em APIs, vamos ter uma visão mais global de APIs. Imagine o seguinte: você e uma equipe de desenvolvedores deseja criar um aplicativo semelhante ao Waze, mas você com certeza não quer reinventar o Google Maps.

Imagine todo o trabalho que você teria, você teria que mapear o país inteiro em um aplicativo, não só o relevo, como também as localizações, e só então você poderia passar a programar o seu App em si. Felizmente, o Google Maps disponibiliza uma API para que você não tenha que fazer isso, e tudo está de maneira simplificada para você acessar sem ter de entender do código interno da API do Google Maps!

Graças a APIs, nossas vidas como desenvolvedores ficam incrivelmente mais fáceis! Podemos acelerar o desenvolvimento de novos projetos sem ter de reinventar a roda.

As restrições do REST

Agora que entendemos o que é uma API, e entendemos o que é REST, basta juntarmos o conceito das duas: uma API RESTful é aquela que utiliza do estilo de arquitetura REST, que tem o conjunto de restrições para criar um serviço-web específico denominado serviço-web RESTful. Ou seja, para uma API ser considerada REST, você precisa seguir todas as restrições do estilo de arquitetura RESTful, será que este é o seu caso?

Vamos ver!

Client Server

Esta é a restrição mais básica do estilo REST, a separação entre cliente-servidor de forma que o cliente não tenha de se preocupar em interagir com o banco de dados, gerenciamento de cache etc, nem o servidor precise se preocupar com a interface do cliente. Ao ter essa independência entre cliente e servidor, o serviço-web se torna mais escalável, uma vez que tem de se preocupar apenas com suas tarefas.

Stateless

Independente do número de requisições que um cliente venha a fazer, cada uma delas deve ser indepentende, o servidor não deve armazenar o estado do cliente, portanto, cada requisição deve conter toda a informação necessária para que o servidor envie uma resposta. O estado de sessão (tal como cookies e tokens) deve ser armazenado somente no lado do cliente, e não no do servidor.

Essa restrição traz as vantagens de visibilidade, pois não é necessário olhar requisições passadas para entender uma requisição feita atualmente, confiabilidade, pois facilita a recuperação de falhas parciais, uma vez que não há requisições dependentes de outras requisições (pense em um efeito em cascata onde uma coisa dá errado e todo o resto dá errado), e, por fim, escalabilidade, porque o servidor não tem de gerenciar o estado do cliente entre suas requisições, e está sempre ficando livre rapidamente, uma vez que cada requisição é independente.

Uma desvantagem disso é que a API REST pode fazer um decréscimo na performance, uma vez que, como não salva o estado das requisições passadas, pode enviar a mesma resposta mais de uma vez, refazendo o processo várias e várias vezes.

Cache

Para aumentar a performance, utiliza-se da restrição cache. Essa restrição requer que o dado de uma resposta seja rotulada com cacheable ou non-cacheable. Se uma resposta for cacheable, então um client cache é dado para reutilizar a resposta mais tarde para requisições equivalentes.

Ao utilizarmos desta restrição, evitamos de fazer requisições repetidas ao servidor, o que evita o processamento de dados desnecessário. Em contrapartida, perde-se um pouco da confiabilidade por não estar tendo a resposta direta do servidor.

Uniform Interface

REST possue uma interface uniforme se comparada a outros estilos de arquitetura. Isso significa que há um contrato para a comunicação entre cliente e servidor, para este contrato ser "assinado", é necessário seguir 4 critérios: identificação do resource, manipulação do resource, resposta auto-explicativa, hypermidia.

Layered System

A sua aplicação deve ser compostas por camadas, de modo que um componente nunca pode ver além da camada de que está ingeragindo diretamente.

Code-On-Demand (Opcional)

Esta restrição permite que o cliente possa executar códigos sob demanda, através de um applet ou script, o que torna possível que diferentes clientes possam se comportar de maneira específica, apesar de possuir o mesmo servidor.

Como este item não faz parte da arquitetura, ele é considerado opcional.

E aí, sua API é RESTful?

Para a sua API ser considerada RESTful, ela deve seguir estritamente todas essas regras, além de possuir um certo nível de coesão e maturidade, definidos na escala de Richardson.

A API da qual estou desenvolvendo não pode ser considerada RESTful, pois não é cacheable, nem layered system, mas não fico triste com isso, nem você deveria, ninguém é obrigado a seguir o padrão, mas, claro, é necessário entender se você não está seguindo por não saber de tal informação, ou se é porque é o melhor para o seu serviço.

De fato, criei uma API, mas ela não é RESTful, e não sabia disso, mas agora entendo mais sobre REST e procurarei aprender mais, uma vez que desejo me tornar full-stack.

Se algum de vocês estiverem afim de se conectar comigo para aprender comigo e eu aprender com vocês, sintam-se livres para me seguir:

github.
linkedin.