Começando do começo: o que é Hypermedia?

Hypermedia é uma extensão lógica de Hypertext, na qual conseguimos combinar gráficos, áudio, vídeo, texto plano e hyperlinks para criar um fluxo de navegação não-linear. (Definição retirada da Wikipedia).

Motivação: REST sem Hypermedia

No artigo de REST que escrevi no começo de 2008 eu falei sobre diversos aspectos importantes em um protocolo de comunicação REST. Recomendo a leitura para quem ainda não tenha visto o artigo. Naquele artigo, cobri praticamente todos os detalhes aos quais devemos prestar atenção – a exceção ficou por conta de Hypermedia.

Para ilustrar uma resposta REST sem uso de Hypermedia, copio aqui uma listagem que usei no artigo de REST da Java Magazine.

HTTP/1.1 200 OK
Date: nnn
Content-Type: text/xml; charset=utf-8
Content-Length: nnn
Last-Modified: Sat, 19 Feb 2008 13:40:03 GMT
 
<?xml version="1.0" ?>
<ofertasDoItem>
<oferta>
<codOferta>23c32440-959a-4c33-b6ee-caff8e41422a</codOferta>
<valor>111.22</valor>
<dataModificacao>2008-02-05</dataModificacao>
<item>
<codItem>b7d24e54-0c0d-4fa0-b4fe-d7cf60180ed7</codItem>
<novo>false</novo>
<vendido>false</vendido>
</item>
<ofertante>
<codUsuario>505ab9d4-4b4b-4ce6-b128-b7408268126c</codUsuario>
</ofertante>
<vencedora>false</vencedora>
</oferta>
<oferta>
<codOferta>41ffac11-5ba2-405b-acc8-8e3d0904b158</codOferta>
<valor>111.22</valor>
<dataModificacao>2008-02-14</dataModificacao>
<item>
<codItem>b7d24e54-0c0d-4fa0-b4fe-d7cf60180ed7</codItem>
<novo>false</novo>
<vendido>false</vendido>
</item>
<ofertante>
<codUsuario>505ab9d4-4b4b-4ce6-b128-b7408268126c</codUsuario>
</ofertante>
<vencedora>false</vencedora>
</oferta>
</ofertasDoItem>

Se você julga que isso parece um grafo de objetos serializado, você não está enganado, é exatamente isso.

O que temos a ganhar com Hypermedia?

Quando implementamos a API REST da autenticação/autorização/cadastro da Globo.com, o protocolo REST sem Hypermedia atendeu perfeitamente. A comunicação funcionou, permitiu integração de clientes de todas as plataformas, de forma desacoplada tecnologicamente. No que será que Hypermedia poderia ajudar?

O cerne do benefício de Hypermedia está no conhecimento prévio que os clientes devem ter sobre o seu protocolo. Repare no seguinte fragmento da resposta:

<item>
<codItem>b7d24e54-0c0d-4fa0-b4fe-d7cf60180ed7</codItem>
<novo>false</novo>
<vendido>false</vendido>
</item>

O que podemos dizer sobre ele? Ele traz informações “quase” completas sobre o item em questão. Todos os atributos estão presentes, porém não dizemos nada ao cliente sobre como interagir com este recurso, não é verdade? Um cliente que receba este XML conseguirá manipulá-lo SE JÁ SOUBER PREVIAMENTE COMO! O cliente já deve conhecer as URIs de cada recurso e saber quais manipulações ele pode fazer sobre os mesmos.

Como Hypermedia pode nos levar além? Com Hypermedia podemos dizer aos clientes como manipular os recursos, e com isso diminuir a inteligência embutida nos clientes.

Exemplo de resposta usando Hypermedia

Agora pegarei um trecho do meu artigo sobre AtomPub para exemplificar uma resposta com uso de Hypermedia:

<?xml version="1.0" encoding="UTF-8"?>
<atom:entry xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:apps="http://schemas.google.com/apps/2006"
xmlns:gd="http://schemas.google.com/g/2005">
<atom:id>https://www.google.com/a/feeds/example.com/user/2.0/SusanJones</atom:id>
<atom:updated>1970-01-01T00:00:00.000Z</atom:updated>
<atom:category scheme="http://schemas.google.com/g/2005#kind"
term="http://schemas.google.com/apps/2006#user"/>
<atom:title type="text">SusanJones</atom:title>
<atom:link rel="self" type="application/atom+xml"
href="https://www.google.com/a/feeds/example.com/user/2.0/SusanJones"/>
<atom:link rel="edit" type="application/atom+xml"
href="https://www.google.com/a/feeds/example.com/user/2.0/SusanJones"/>
<apps:login userName="SusanJones" suspended="false" admin="false" changePasswordAtNextLogin="false" agreedToTerms="true"/>
<apps:name familyName="Jones" givenName="Susan"/>
<gd:feedLink rel="http://schemas.google.com/apps/2006#user.nicknames"
href="https://www.google.com/a/feeds/example.com/nickname/2.0?
username=Susy-1321"/>
<gd:feedLink rel="http://schemas.google.com/apps/2006#user.emailLists"
href="https://www.google.com/a/feeds/example.com/emailList/2.0?
recipient=us-sales@example.com"/>
</atom:entry>

Qual é a principal diferença aqui? Através do uso de links conseguimos indicar uma URI para manipulação do recurso, e através do atributo rel, indicamos QUAL é a manipulação. Algumas coisas ainda ficam implícitas. Por exemplo, se o link indica um rel=”edit”, a manipulação em questão provavelmente será feita com uma requisição HTTP PUT. Se o link tiver um rel=”show”, a manipulação deve ser uma leitura, feita com HTTP GET.

Hypermedia x Acoplamento

Neste ponto deve ter ficado claro que o uso de Hypermedia confere maior significado ao protocolo de comunicação. Em vez de trafegar dados crus, enviamos também metadados que permitem a construção de clientes mais genéricos dos nossos serviços.

Reduzindo o conhecimento que os clientes têm sobre o servidor, naturalmente o acoplamento diminui. O servidor precisa manter fixa apenas  a URI inicial da conversação, pois as posteriores serão informadas durante a comunicação.

O servidor pode também utilizar múltiplos tipos de conteúdo, de forma que alguns clientes consigam interagir de forma mais ampla. Um exemplo seria um IPod que sabe consumir podcasts, enquanto estes seriam ignorados por um browser comum.

Precisamos de Hypermedia em um protocolo REST?

Resposta curta: na minha opinião não.

Resposta longa: espero que minha resposta curta não tenha deixado a impressão de que não valorizo Hypermedia. Muito pelo contrário, acho que um protocolo que use Hypermedia será muito elegante e terá baixo acomplamento.

Entretanto, construir protocolos para clientes genéricos é bem mais difícil. Em alguns casos a decisão de diminuir o acoplamento aumenta na mesma proporção a complexidade do protocolo de comunicação envolvido.

É perfeitamente possível criar um excelente protocolo de comunicação sem Hypermedia. Você poderá ter clientes de múltiplas plataformas, conversando com seu servidor em múltiplos formatos de conteúdo.

Há um ponto de atenção no quanto seus clientes conhecem sobre seus formatos de URIs. Sem Hypermedia, mudanças de URIs podem quebrar seus clientes, o que traz um nível de acoplamento maior do que o existente com Hypermedia.

Recomendação geral: o uso de Hypermedia é consistente com a arquitetura da web, utilizada há muitos anos com sucesso. Quando um protocolo de comunicação REST faz uso de Hypermedia, o acoplamento fica baixo e nos dá bastante liberdade para evolução. O ideal é tentar usar Hypermedia ao máximo desde o começo, mas sempre ponderando o nível de complexidade na construção dos clientes.

Eu já utilizei bastante o Apache na remota época em que eu desenvolvia algumas coisas em Php. Na verdade não fazia nada de muito sofisticado, mas tinha boa familiaridade com os módulos, com a configuração, essas coisas. Depois que foquei mais no uso de servidores de aplicação Java, deixei o Apache em segundo plano. Praticamente só vinha usando o Apache para servir conteúdo estático, e claro, nele também ficam configurados os conectores para comunicação com os servidores de aplicação.

Como tenho trabalhado bastante com web services REST, venho tentando explorar ao máximo os recursos do HTTP para elaborar protocolos de comunicação concisos e intuitivos. Neste sentido, o Apache oferece recursos muito interessantes. Por exemplo, quando utilizamos URIs no formato /usuario/123456/item/25 para representar um determinado item de um determinado usuário, a resposta a esta requisição é cacheável pelo Apache. Entretanto, ao utilizar URIs neste formato você precisa definir uma forma de fazer o parsing da URI para pegar os parâmetros relevantes.

No meu artigo de REST da Java Magazine de Abril eu usei o StringTokenizer do JDK para fazer a quebra da URI e pegar os valores que me interessavam. A JSR-311 define uma forma bem interessante de fazer isso com annotations também. E hoje fui descobrir que o mod_rewrite também pode fazer facilmente a quebra de URIs neste formato em URIs com parâmetros em query string por exemplo.

Uma utilização inteligente do cache do servidor web e de módulos de proxy também pode tornar a arquitetura da aplicação bem eficiente e reduzir bastante a carga sobre os servidores de aplicação. Se eu posso utilizar diretamente o cache do Apache para várias URIs, não vale a pena deixar as requisições chegarem ao container de servlets, mesmo que ele responda também com dados em cache.

Vendo o poder e a facilidade de uso de alguns módulos do Apache, me sinto obrigado a ter total familiaridade com ele novamente. Aos poucos irei estudando e integrando os módulos do Apache à arquitetura das minhas aplicações REST, pois isto pode trazer um belo ganho de performance e escalabilidade. Afinal de contas, quem quer explorar a fundo os recursos do HTTP não pode abrir mão de explorar a fundo um servidor tão confiável e maduro como o Apache, não é mesmo?

OBS: uns anos atrás eu dizia pra mim mesmo que o dia que eu conhecesse pelo menos vagamente metade dos projetos na home da Apache Software Foundation eu já teria uma boa bagagem. Hoje em dia já conheço mais da metade do projetos da home, e admiro cada vez mais esta fundação. O mundo open source não chegaria aos pés do que é hoje sem a existência da ASF. Um belo exemplo de qualidade em software!

Como achei a documentação disso bem fraquinha no site do projeto, resolvi postar aqui um exemplo de código para facilitar quem possa precisar (e a mim mesmo no futuro). Este exemplo é um método de teste junit bem simples que monta uma requisição RESTful de cadastro de um novo usuário, especificando as configurações do proxy na API. Utilizei o XStream para fazer as manipulações XML. Segue o exemplo:

public void testCriacao() throws HttpException, IOException{
Usuario novoUsuario = new Usuario();
novoUsuario.setLogin("fulano");
novoUsuario.setSenha("123456");
novoUsuario.setNome("Fulano");
novoUsuario.setSobrenome("da Silva");
novoUsuario.setStatusConta(1);
novoUsuario.setTamanhoMailBox(6144);

HttpClient client = new HttpClient();
//servidor remoto que iremos acessar
HostConfiguration hostConfiguration = new HostConfiguration();
hostConfiguration.setHost("www.domain.com", 8080);
// proxy pelo qual precisamos passar
ProxyHost proxy = new ProxyHost("10.10.10.10", 9090);
hostConfiguration.setProxyHost(proxy);
client.setHostConfiguration(hostConfiguration);

PostMethod method = new PostMethod("http://www.domain.com:8080/MailIntegration/usuario/");
XStream xstream = new XStream();
xstream.alias("usuario", Usuario.class);
String usuarioXml = xstream.toXML(novoUsuario);
StringRequestEntity requestEntity = new StringRequestEntity(usuarioXml, "text/xml", "UTF-8");
method.setRequestEntity(requestEntity);
int statusCode = client.executeMethod(method);
assertEquals(201, statusCode);
Usuario usuarioCadastrado = (Usuario)xstream.fromXML(method.getResponseBodyAsStream());


Após alguma pesquisa e alguns testes, descobri que o Firefox suporta de fato os métodos HTTP PUT e HTTP DELETE. Eles não podem ser usados em formulários, entretanto. Se você tentar utilizar algum método diferente de GET e POST em um formulário, o browser converte a requisição para GET.

Já o XmlHttpRequest suporta estes métodos, e o RESTFox certamente faria uso disto, e não de um formulário. Sabendo que a idéia é válida, tentarei em breve começar o desenvolvimento do plugin, e quando já tver algo concreto coloco aqui.

Este fim de semana o James Snell implementou um adapter do Apache Abdera para o CouchDB. Este adapter permite que se consiga facilmente implementar um armazenamento de dados no formato Atom com uso de uma instância do CouchDB.

Como eu já mencionei anteriormente, o Abdera oferece uma API para manipulação de conteúdo no formato Atom e a realização de operações do Atom Publishing Protocol. Já o CouchDB é um banco de dados orientado a documentos que é escrito em Erlang e foi projetado para extrema escalabilidade e permite fácil instalação em servidores com múltiplos núcleos ou em clusters de máquinas.

Em vez de utilizar tabelas com colunas (como os bancos de dados relacionais), o CouchDB armazena os documentos em formato JSON e disponibiliza como interface uma API Restful, com clientes já implementados em várias linguagens, como Javascript, Java, PHP, Ruby e Python.

Acho que isto expressa muito bem o horizonte que vem se formando. Em vez de pilha de tecnologias e protocolos proprietários, temos diversas tecnologias e plataformas diferentes conseguindo se comunicar através de HTTP. Um projeto open source Java que manipula conteúdo Atom já disponibiliza com facilidade um mecanismo de integração com serviços REST que manipulam dados em formato JSON.

É impressão minha ou estamos de fato vendo rapidamente uma mudança radical de abordagem na vanguarda da tecnologia? A mesma IBM que antigamente dominava de forma absoluta todo o mercado de hardware e software com soluções proprietárias agora patrocina diversos projetos open source e mantém sua elite intelectual trabalhando nestes projetos.

Soluções open source estão liderando várias frentes de desenvolvimento e com isso rapidamente surgem integrações entre componentes feitos em diferentes linguagens e plataformas. O conhecimento não está mais guardado a 7 chaves, e sim discutido abertamente por uma comunidade que aceita qualquer um com capacidade para agregar idéias boas.

A criatividade e a iniciativa individual nunca tiveram tanto poder, e isto é fabuloso. Com isso, claro que a versatilidade e o conhecimento diversificado ficam muito valiosos.

Hum… maybe it’s time for me to fight my disgust for Javascript and start developing something nice including JSON