REST, RESTlike e RESTful (e o GraphQL?)
A arquitetura REST propõe basicamente um catálogo de endereços bem definido. Basicamente a padronização de rotas de API na comunicação cliente/servidor com ações basicamente verbais via requisições HTTP (stateless) com destino a endereços conhecidos de um servidor. Requisições HTTP enviadas http://site.com/objeto/ação interagindo com GET, POST, PUT, DELETE e retornos de texto puro ou dados estruturados e serializados XML, JSON. Em casos especiais, rotas REST podem retornar tipos variados de recurso, como texto puro, HTML, arquivos, imagens, vídeos, músicas e etc.
Um bom começo para um projeto de software é projetar como será sua API: a forma como se dará sua comunicação com os clientes e outros servidores. Surge então a proposta REST – Transferência de Estado Representacional – conhecida por sua presença dominante em sistemas da web como Redes Sociais, E-commerce, Ensino a Distância e tantos outros.
O problema que REST tenta mitigar
A comunicação cliente/servidor e servidor/servidor se torna um problema quando não existe um planejamento da sintaxe das rotas (endpoints) para obtenção de informações. Arquitetura em padrão REST estabelece rotas intuitivas como http://site.com/objeto/acao para facilitar o consumo da informação a que se pretende disponibilizar.
REST
REST é um conceito de arquitetura para padronizar endereços de APIs. Dados estruturados JSON são tão utilizados quanto XML para requisições e respostas. Transferência de Estado Representacional a que se refere, está relacionada à forma como se dá a transmissão da informação no ciclo de vida da aplicação.
RESTful
Sistemas API arquitetados com vistas a acessos REST e uso semântico dos métodos HTTP GET, POST, PUT, PATCH, DELETE são chamados RESTFUL.
RESTFUL endereça nomes de recursos junto a métodos HTTP para realizar operações.
RESTlike
RESTlike são sistemas que seguem parcialmente a regra da semântica REST. Essa é a diferença em relação ao RESTful. A adoção de RESTlike na arquitetura do software, ocorre devido a problemas na arquitetura legada ou necessidade de flexibilidade nas rotas.
Cabeçalhos de requisição e resposta HTTP
GET /exemplo HTTP/1.0
HTTP/1.0 200 <conteúdo> </conteúdo>
Utilização nas APIs
- Ambientes web, onde requisições são realizadas tanto por usuários (clientes) quanto outros sistemas. A aplicação servidora responde com dados.
- Utilizar PUT (ou patch quando parcial) é necessário pois evita o risco de persistir a mesma informação duas vezes.
Benefícios de REST
- Válido e portável para diversas linguagens web
- Padrão de comunicação com servidor
- Mapeamento dos serviços de uma aplicação
- Simplicidade nas operações com dados
Evoluindo de RESTlike para RESTful
Agora que vimos que RESTlike é um quase-RESTFUL, provavelmente queremos refatorar nossas APIs, tornando-as coesas como propõe RESTFUL. Tomar essa decisão de mudança em um sistema em produção custa caro. Deve-se considerar muitos fatores de peso para que isso seja considerado necessário. Mas como resolver o problema? Bom, caso haja realmente essa pretensão, deve-se pensar no versionamento de API como alternativa, de tal forma que as rotas RESTlike existentes (v.1) sejam mantidas e as novas (v.2) RESTful possam ser oferecidas como nova versão de API, desativando as versões mais antigas gradativamente.
O advento do GraphQL
GraphQL é mais uma forma de acesso a dados, e tem demonstrado ser uma ótima alternativa ao REST. Não é necessário substituir suas API’s REST por GraphQL sem uma justificativa plausível, visto que são apenas diferentes “linguagens” para manipulação de dados que realizam a mesma função.
Leia mais sobre Versionamento Semântico
Leia mais sobre O que o empreendedor precisa saber sobre software?
Quer saber mais sobre como funciona? Fale com um desenvolvedor agora mesmo!
WhatsAppO conteudo foi útil? Isso é fantástico. Quer incentivar mais posts como esse? Mostre seu apoio com qualquer valor.
Chave PIX: d0311e58-cb6e-4d47-b3d8-3d4254763ce7
