O mercado define REST como serviços HTTP que fornecem recursos, geralmente em JSON, através dos verbos GET, PUT, POST e DELETE. Embora, esses serviços possam ser REST, o conceito vai além.

Nosso sentimento é que, por desconhecer as ideias que nortearam o surgimento do conceito, implementadores de REST acabam perdendo boas oportunidades de constuir arquiteturas mais robustas. Essa é a motivação dessa série.

Origem e significado de REST

REST (REpresentational State Transfer) é um estilo arquitetural proposto por Roy Thomas Fielding, em 2000, em sua dissertação de PhD (Architectural Styles and the Design of Network-based Software Architectures). Se você implementa serviços RESTful, deveria ler o trabalho de Fielding.

O primeiro capítulo do trabalho de Fielding é, inclusive, uma excelente referência para definições relacionadas a Arquitetura de Software.

REST é um estilo arquitetural para aplicações baseadas em rede.

Ele menciona e aceita a diferenciação proposta por Tanenbaum, que aponta que sistemas distribuídos são geralmente percebidos por seus usuários como unidade, mesmo rodando em múltiplas CPUs. Ainda seguindo Tanenbaum, sistemas baseados em rede operam através de uma rede e isso fica transparente para seus usuários.

REST foi concebido sob cinco grandes ideiais (constraints) fundamentais:

1. Cliente-Servidor: a comunicação ocorre entre dois agentes, em rede, onde um agente é considerado cliente e outro é considerado servidor. O cliente, ativamente, faz requisições que devem ser respondidas pelo servidor.
2. Cache: tanto o agente servidor quanto cliente podem implementar estratégias de caching com vistas a melhoria da performance de rede e a percebida pelo usuário.
3. Stateless: o agente servidor não deverá manter nenhum tipo de estado entre duas ou mais requisições. Uma única requisição deve conter todos os parâmetros necessários para ser atendida sem ter de contar com nenhum tipo de “memória” do agente servidor.
4. Layered: A comunicação entre cliente e servidor deve ocorrer através de camadas (arquitetura pipe-and-filter). Onde camadas podem ser adicionadas para melhorar a performance do sistema (por exemplo, implementando caching)
5. Interface Uniforme: a troca de mensagens entre cliente e servidor deve ocorrer através de interfaces uniformes, ou assemelhadas, tanto em modo quanto em formato.

Há ainda uma sexta ideia (constraint) que é “código sob demanda”. Ou seja, a capacidade do servidor “fornecer” código para ser executado no cliente. Esse conceito é tido como opcional.

O que REST, necessariamente, não é

Fielding não indica que a implementação de REST deva se restringir a algum protocolo. Logo, não precisa ser HTTP. Ele também não especifica um formato. Logo, não precisamos adotar obrigatoriamente XML ou JSON.

Na prática, [tweet]na maioria das vezes que ouvimos as pessoas falarem em “API REST”, na verdade querem dizer “API HTTP com dados em JSON”. Por incrível que pareça, nem sempre RESTful.[/tweet]

RESTful?

Uma API implementada conforme as indicações do trabalho de Fielding, implementando os cinco princípios fundamentais, é dita “RESTful”.  Entretanto, é importante salientar que é plenamente possível (e frequente, infelizmente) que APIs RESTful não sejam boas APIs.

Concluindo

REST é um padrão arquitetural, formalmente definido, que requer que princípios sejam rigidamente observados.

Nem toda API HTTP que retorne recursos formatados como JSON ou XML é, necessariamente, RESTful. Aliás, APIs RESTful podem ser implementadas sem usar HTTP, nem JSON ou XML.

Em posts futuros, vamos analisar mais as recomendações de Fielding e verificar como elas podem nos ajudar a criar APIs mais sólidas (RESTful ou não).

NOTA: Recomendamos assistir essa breve entrevista de Fielding sobre REST.