Modelo de maturidade REST

Ainda não é REST

Como alcançar REST? Quão maduro é a minha aplicação em relação a REST? O modelo de Leonard Richardson foi amplamente discutido e comentado, inclusive no “Rest in Practice” (um livro que recomendo a leitura). Mas o que ficou faltando nesse modelo de maturidade? Por que o nível máximo não implica ainda em REST?

Nesse post, mais teórico, descrevemos um modelo que aborda o que é REST. Em próximos posts teremos vídeos e descrições de como aplicar REST na prática, fugindo do mundo de “serviços REST”.

De acordo com o modelo, nível 3 adiciona suporte a hipermídia, aperfeiçoando um sistema através do uso de linked data – um requerimento fundamental para REST. Mas HATEOAS sozinho não implica em REST, como o próprio Roy já mencionou.

Lembremos como RMI e objetos distribuídos permitiam a navegação dentre objetos e seus estados? O exemplo a seguir ilustra tal situação:


orders = RemoteSystem.locate().orders();
System.out.println(orders.get(0).getProducts().get(0));
receipt = order.payment(payment_information);
System.out.println(receipt.getCode());


Mas e se o código acima for uma sequência de invocações remotas de EJB? Se navegando através de relacionamentos (linked data) é REST, implementar o código acima a través de HTTP também seria (fora a falta de uniform interface).

O modelo se aproxima de REST no lado do servidor, e Rest in Practice chega a REST em ambos os lados, descrevendo a importância da semantica e de media types. O resto desse post descreve o que ficou de fora desse modelo de “serviços REST via web”, que na realidade são “serviços via web”.

O que ficou faltando?

O exemplo anterior não inspecionou a representação atual e relacionamentos antes de decidir qual seria o próximo passo e isso cria um alto acoplamento inexistente em aplicações REST.

O exemplo anterior contem um conjunto fixo de instruções a ser seguido, independentemente de qualquer resposta do servidor. O cliente não se adapta, não responde ao resultado de suas interações, mas assume um processo fixo.

“The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.“.

Se a API fosse http e o servidor respondesse com “Server too busy”, um cliente REST de verdade tentaria novamente em 10 minutos, o que os clientes tradicionais que escrevemos não fazem.

Mesmo alcançando o máximo de maturidade no modelo de Richardson, a aplicação que envolve cliente e servidor, não se adapta ao estado do recurso, ainda não é REST: seu cliente ainda possui um alto acoplamento.

Por esse motivo não existe tal serviço como REST web service, mas para ter uma aplicação REST, tanto o cliente quanto o servidor devem seguir suas características arquiteturais.

Modelo de Richardson e HTTP

Relações ricas em semânticas podem ser compreendidas por clientes e são fundamentais para a criação de um sistema REST. Um ponto importante é lembrar que o modelo continua sendo muito importante para demonstrar a maturidade de uma arquitetura em cima do uso de HTTP, mas ainda não impede o alto consumo financeiro vindo do uso do “mindset de web services” de maneira mais elegante, mas com o mesmo custo de acoplamento.

Um modelo de maturidade REST

Por todos esses motivos, proponho um modelo de maturidade independente do protocolo, onde podemos medir o uso dos aspectos de REST em um sistema:

Rest Architecture Maturity

Para atingir REST, o primeiro passo é a utilização de uma uniform interface: um conjunto padrão de ações que podem ser executadas em todos os recursos existentes. Por exemplo, em HTTP, os verbos definem a interface uniforme, o que pode ser efetuado com cada recurso.

O segundo passo é a adoção de linked data para permitir ao cliente navegar entre estados e recursos de maneira uniforme. Através de HTTP, como o modelo de Richardson descreve, este é o uso de hypermídia como connectedness.

O terceiro passo é adicionar valor semântico aos links. Relações definidas como “related” podem possuir valor semântico em determinados processos, menos valor em outros. “payment” pode fazer senido para outros. A criação e adoção de media types permitem – mas não implicam – em código sendo escrito de maneira menos acoplada.

O quarto passo é criar clientes de maneira que suas decisões sejam baseadas nos relacionamentos e estado de recursos, além do conhecimento do media type. É o media type e seus relacionamentos que criam o acoplamento entre clientes e servidores, qualquer outro acoplamento vem de arquiteturas que não REST.

Todos os passos acima devem ser tomados para minimizar o acoplamento do cliente ao servidor – e vice versa.

O último passo é a evolução do cliente. Code on demand permite educar clientes como se comportar em situações específicas que não foram previstas, como por exemplo ao encontrar um novo media type desconhecido.

Note que para a adoção de REST, o modelo apresentado no gráfico, nenhuma menção foi feita ao protocolo HTTP (somente exemplos), pois REST é agnóstico ao mesmo.

O post a seguir descreve como criar um cliente REST e suas vantagens.