29 de junho
Dicas
335 visualizações

REST, RESTlike e RESTful

RESTlike e RESTFUL são duas maneiras para arquitetar os endereços de recursos em aplicações web com base em REST, sendo que REStlike é uma abordagem simplista, flexível e RESTful está compromissada com aplicação rigorosa de rotas e métodos coesos.

A arquitetura REST propõe 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/acao interagindo com GET, POST, PUT, DELETE e retornos de texto puro ou dados estruturados e serializados XML, JSON e, por vezes, HTML.

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 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, devido a uma problema na arquitetura legada ou por opção do desenvolvedor.

Utilizar PUT (ou patch quando parcial) é necessário pois evita o risco de persistir a mesma informação duas vezes.

Cabeçalhos de requisição e resposta HTTP

Requisição:
GET /exemplo HTTP/1.0
Resposta:
HTTP/1.0 200

Utilização nas APIs

  • Ambientes web, onde requisições são realizadas por usuários (clientes) e servidores respondem com dados.

Benefícios de REST

  • 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.

Um pouco sobre o autor

Matteus Barbosa - Desenvolvedor Web
Trabalho como Desenvolvedor web, no regime MEI PJ (Pessoa Jurídica) seguindo preceitos da legalidade. Para saber da minha experiência, acesse meu Currículo, meu Portfólio, a relação de Referências de Clientes ou ainda a Lista de Serviços. As propostas de serviço são iniciadas com conversas informais, seguidas da coleta de requisitos, elaboração do cronograma e por fim a proposta de orçamento. Todas as etapas são acompanhados de perto via ferramenta online e videoconferências. Os pagamentos são registrados com entrega de notas fiscais. Presto serviços de projeto, desenvolvimento e manutenção de sistemas baseados nos mais diversos frameworks.