REST: um ótimo primeiro passo

#REST

Por que eu devo ler esse artigo?

Segundo Nordic API:

"APIs REST têm uma taxa de adoção de 93,4%, o que faz a arquitetura queridinha dos desenvolvedores."

Apenas com a informação acima, você deveria estar motivado para aprender a arquitetura Rest seja através desse artigo ou até em outras fontes de conhecimento. Mas eu encorajo você a ficar e terminar de ler, pois eu realizei diversas pesquisas e deixei aqui os principais conceitos que você deve saber ao terminar esse artigo.

Obs: Na última seção vou deixar alguns links para se aprofundar.

Mas o que vou aprender?

Definição de API;
O que é uma arquitetura Rest;
Níveis de maturidade;

Definição de API:

Antes de mergulhar no mundo da arquitetura REST, devemos entender o conceito de Application Interface Programming (API), o qual é traduzido como Interface de programação de aplicação. Esse conceito está longe de ser algo complexo, basicamente podemos resumir ele como um conjunto de rotinas, definições e protocolos para criação de aplicações de software.

Por exemplo, vamos supor que eu tenha uma aplicação web que tenha as seguintes finalidades:

salvar opiniões, críticas ou reviews de um determinado anime;
realizar um processamento sobre os dados armazenados para extrair algumas conclusões como: anime mais amado, mais odiado e etc;
disponibilizar essas informações para que outras pessoas ou softwares possam consumir.

A minha aplicação precisa definir meios de acessos para que alguém ou algum software possa salvar e recuperar informações. Caso contrário, a minha solução seria inútil, aliás, qualquer solução computacional que não interaja com o meio externo é inútil. Esses meios de acesso bem definidos são conhecidos como interface e o conceito de uma aplicação que consegue interagir com o meio externo através da interface é conhecido como API.

Com isso, a gente consegue afirmar que o usuário que vai utilizar a minha aplicação não precisa saber como eu implementei essa solução, apenas em como acessar.

O que é REST:

O REST é um sistema que consiste em ter dois agentes, um que realiza requisições denominado como cliente e outro que entrega um recurso nomeado como servidor. A empresa RedHat define esse sistema como:

REST is a set of architectural constraints, not a protocol or a standard. API developers can implement REST in a variety of ways.

REST é um conjunto de restrições arquitetônicas e não um protocolo ou um padrão. Desenvolvedores de API podem implementar REST de diversas maneiras (tradução livre).

Sendo assim, podemos entender que REST, de Representation State Transfer, é uma maneira de implementar API. E deve seguir uma séries de critérios, ao total seis, definidos como:

Interface uniforme;
Não guarda estado;
Permite utilizar cache;
Cliente-Servidor;
Sistema em camadas;
Código sob demanda.

A seguir vou explicar cada conceito listado acima.

Interface Uniforme

Esse conceito é a principal restrição que divide a API REST das Não-REST. Ela sugere que deve existir um meio uniforme de interação com servidor, independente de aplicação cliente. Ou seja, o cliente pode ser um website ou um aplicativo mobile, mas a maneira de interação é a mesma para todos.

Para implementar este conceito, existem quatro diretrizes:

Cada recurso do servidor é identificado na requisição. Por exemplo, quero acessar vários comentários sobre o anime Naruto, então vou identificar esse recurso como anime/naruto na requisição.
Manipulação de recursos através do estado, isto é, o cliente tem representação do recurso e ele contém informação suficiente para modificar ou deletar o recurso no servidor, caso o cliente tenha autorização para isso.
Cada mensagem inclui informações suficientes para descrever como processar a mensagem para que o servidor possa analisar a requisição sem muitos problemas.
Implementar HATEOAS, haverá uma seção só para esse conceito.

Stateless

Essa ideia diz que o servidor não guarda as informações de requisições realizadas. Logo o cliente deve incluir todas as informações necessárias para o processamento da parte do servidor. Essas informações podem ser enviadas no cabeçalho, na URI ou até como parâmetros.

Cacheable

Cada resposta deve dizer se o dado enviado pode ser mantido em uma cache ou não e se sim, quanto tempo essa informação pode ser guardada no lado do cliente.

Cliente-Servidor

Como dito anteriormente, todas as aplicações REST devem ser uma arquitetura Cliente e Servidor. Porém não deve haver dependência entre esses componentes e eles podem evoluir de forma independentes.

Sistemas em camadas

Uma arquitetura de aplicação deve ser composta por várias camadas. Cada camada não tem conhecimento sobre as outras camadas além daquela imediatamente superior, e pode haver vários servidores intermediários entre o cliente e o servidor final. Esses servidores intermediários podem aprimorar a disponibilidade do sistema ao permitir o balanceamento de carga e ao fornecer caches compartilhados.

Código sob demanda

Os servidores podem também fornecer código executável para o cliente.

Esse conceito não necessariamente precisa ser implementado.

Níveis de maturidade REST

O modelo de maturidade de Richardson é uma forma popular de avaliar a conformidade de uma API com os princípios REST. Leonard Richardson, que criou este modelo, propõe quatro níveis de maturidade que descrevem a transição de uma API do estilo RPC (Remote Procedure Call) para uma verdadeira API RESTful. Cada nível introduz novos conceitos do REST, aumentando a adesão aos seus princípios. Aqui estão os quatro níveis:

Nível 0: O Pântano de POX

Descrição: Este nível é o ponto de partida para muitas APIs e é caracterizado pelo uso de HTTP apenas como um meio de transporte para chamadas de procedimento remoto (RPC), geralmente utilizando XML (Plain Old XML - POX). Não aproveita os recursos do HTTP além do básico.
Características: Uma única URI, um único método HTTP (geralmente POST), e toda a comunicação é feita através de payloads XML ou JSON.

Nível 1: Recursos

Descrição: Neste nível, a API começa a definir recursos individuais usando URIs diferentes. Cada recurso é identificado de forma única através da sua URI.
Características: Uso de várias URIs para representar diferentes entidades ou recursos, mas geralmente ainda limitando-se ao uso de um método HTTP (como POST) para operações.

Nível 2: Verbos HTTP

Descrição: A API passa a utilizar os verbos HTTP (GET, POST, PUT, DELETE, etc.) para definir ações sobre os recursos. Isso permite uma interação mais rica e significativa, aproveitando o protocolo HTTP de forma mais completa.
Características: Emprego dos verbos HTTP para representar operações CRUD (Criar, Ler, Atualizar, Deletar) sobre os recursos. Uso de cabeçalhos HTTP para metadados, status codes para representar o resultado das operações.

Nível 3: HATEOAS (Hypermedia As The Engine Of Application State)

Descrição: Este é o nível mais alto de maturidade, onde a API se torna verdadeiramente RESTful. HATEOAS refere-se à inclusão de hiperlinks nas respostas da API que orientam o consumidor sobre as ações subsequentes possíveis a partir do estado atual.
Características: Respostas que incluem links para outros recursos ou ações, permitindo ao cliente navegar pela API sem conhecimento prévio das URIs. Promove a descoberta de recursos e ações de forma dinâmica.

A adesão ao Nível 3 do Modelo de Maturidade de Richardson é geralmente considerada uma marca de uma API RESTful bem projetada, fornecendo uma interface rica e flexível para os consumidores da API.

Links sobre:

Quer entrar em contato comigo, entre através do meu:

Github: https://github.com/iyisakuma
Linkedin: https://www.linkedin.com/in/iyisakuma/
Gmail: iyisakuma@gmail.com