Existe um debate intenso sobre a melhor abordagem para comunicação entre aplicações heterogêneas. Embora soluções baseadas em SOAP, WSDL e especificações WS-* dominem, uma voz crescente defende que o REST (Representational State Transfer) apresenta uma alternativa mais elegante. Este artigo oferece uma visão prática do REST e da integração de aplicações via HTTP RESTful.

Os Cinco Princípios Fundamentais

Uma implementação REST adere aos seguintes pilares:

• Identificação Universal de Recursos
• Navegação via Hiperlinks
• Uso de Métodos HTTP Padrão
• Múltiplas Representações de Recursos
• Comunicação sem Estado

Identificação Universal de Recursos

Cada conceito significativo na sua aplicação—seja um objeto de domínio, uma coleção ou um processo—deve possuir um identificador único e global. No contexto da web, este identificador é o URI (Uniform Resource Identifier). Utilizar URIs como identificadores oferece um esquema de nomenclatura já estabelecido e universalmente compreendido.

Considere uma aplicação de comércio eletrônico. É crucial que cada produto, pedido e cliente possua um URI exclusivo. Isto permite que links sejam compartilhados, salvos como favoritos ou referenciados facilmente. A preocupação de expor IDs de banco de dados diretamente é um mito: o recurso identificado pelo URI é tipicamente uma abstração de alto nível, como um pedido completo que pode incluir itens, endereço e detalhes de pagamento.

Exemplos de URIs para recursos:

http://api.loja.com/clientes/7890
http://api.loja.com/pedidos/2023/12/112233
http://api.loja.com/catalogo?genero=infantil

Navegação via Hiperlinks

Um sistema RESTful emprega hiperlinks (hipermídia) para navegação entre recursos, implementando o conceito de "Hipermídia como o Motor do Estado da Aplicação" (HATEOAS). A representação de um recurso frequentemente contém links para recursos relacionados, guiando o cliente sobre as ações disponíveis.

Exemplo de representação XML com links:

<pedido url="http://api.loja.com/pedidos/112233">
    <valor_total>159.90</valor_total>
    <item href="http://api.loja.com/produtos/9876"/>
    <cliente href="http://api.loja.com/clientes/7890"/>
    <status href="http://api.loja.com/pedidos/112233/entrega"/>
</pedido>

Esta abordagem torna o estado da aplicação explícito e transita entre estados através da requisição de representações que contêm os links necessários.

Uso de Métodos HTTP Padrão

Os recursos devem expor uma interface uniforme usando os métodos (verbos) definidos pelo protocolo HTTP. Os principais são:

• GET: Recupera uma representação segura e idempotente de um recurso.
• POST: Cria um novo sub-recurso ou envia dados para processamento. Não é idempotente.
• PUT: Atualiza completamente um recurso existente ou o cria se não existir na URI fornecida. É idempotente.
• DELETE: Remove um recurso identificado. É idempotente.

Esta uniformidade permite que componentes genéricos (como caches, proxies e navegadores) interajam com sua aplicação. Projetar operações específicas (ex.: getDetalhesCliente, criarPedido) em vez de mapear para os métodos HTTP padrão frequentemente resulta em uma interface RPC sobre HTTP, não no estilo REST.

Múltiplas Representações de Recursos

Um único recurso pode ter diversas representações (ex.: JSON, XML, HTML, imagem). O cliente negocia a representação desejada usando o cabeçalho Accept. O servidor responde com o formato correspondente, indicando-o no cabeçalho Content-Type.

Requisição solicitando formato específico:

GET /clientes/7890 HTTP/1.1
Host: api.loja.com
Accept: application/json

Esta flexibilidade permite que a mesma API seja consumida por aplicativos web, móveis e outros serviços, cada um recebendo a representação mais adequada.

Comunicação sem Estado

Cada requisição do cliente deve conter toda a informação necessária para o servidor processá-la. O servidor não mantém contexto do cliente entre requisições. Isso melhora a escalabilidade, pois qualquer servidor de um cluster pode atender qualquer requisição. O estado da aplicação é mantido pelo cliente (ex.: via tokens) ou implicitamente contido nos recursos acessados através dos links.

REST na Teoria e na Prática

REST é um estilo arquitetural definido por Roy Fielding em sua dissertação, que descreve os princípios por trás da web. A implementação HTTP + URI é a instanciação mais proeminente deste estilo. O termo "RESTful HTTP" refere-se a aplicações que seguem rigorosamente os princípios REST ao usar o protocolo HTTP. Muitas APIs ditas "REST" são na verdade apenas APIs HTTP que não aderem a princípios como hiperlinks e interface uniforme, perdendo benefícios como explorabilidade e desacoplamento.

Para construir APIs verdadeiramente RESTful, é essencial abraçar estes princípios em conjunto, tratando a web como uma plataforma de integração nativa.