Diminuindo acoplamento de sistemas com REST, e video!

Muitos ainda me perguntam qual é a real vantagem do REST sobre os modelos mais tradicionais . Ao integrar sistemas, a implementação de acesso ou de processos costuma ser feita de maneira sequencial, onde esperamos resultados específicos de nosso servidor.

Esperar um resultado específico de um servidor é criar um grande acoplamento, e desejamos diminuir isso.

Em clientes REST, e em business processes modelados com REST, atingimos um nível de desacoplamento bem maior. Imagine o sistema a seguir (entre outros) que efetuaria compras em um site como a amazon:

Quando tem um item que quero comprar E tem um carrinho de compras Mas nao desejei nada Entao deseje este produto primeiramente Quando tem um item que quero comprar E tem um carrinho de compras Entao deseje este produto Quando estou no carrinho E ainda quero comprar produtos Entao começe novamente Quando tem um pagamento Entao prepare o pagamento

O código acima funciona e pode ser visto em execução na terceira parte da série Rest do zero. Nesse processo modelado como Rest, diversas evoluções poderão ocorrer no servidor sem quebrar o cliente, como por exemplo:

1. Após adicionar um produto ao carrinho, caso o servidor passe a redirecionar para uma sugestão de produto ao invés do carrinho, o cliente continua funcionando normalmente.

2. Caso não encontre um dos produtos, o cliente consegue pagar.

3. Caso o servidor não possua o produto, passará um link para outra empresa que vende ele, e eu executarei o processo na outra empresa, sem perceber nada.

4. Se eu desejar fazer a compra desde o início em outro site, que não a amazon, basta mudar o ponto de entrada de uma URI da amazon para uma URI de outro sistema.

Note que nos beneficiamos com compatibilidade com código antigo, futuro e ainda somos capazes de atingir novos objetivos em outros sistemas sem saber da existência dos mesmos. Além disso passamos a poder comparar preço em diversos sites sem mudar uma linha de código, utilizando media types conhecidos (como Atom ou RDFa).

Esse poder não é alcançado com modelos tradicionais de processo, e por vezes é deixado de lado. É isso que REST e hipermídia traz para nossos sistemas, por exemplo.

Os modelos tradicionais acabam utilizando mensagens que são comandos ao invés de trocar documentos. Apesar de nossa DSL parecer um comando ela é somente uma DSL customizável, executando a troca de documentos que você desejar.

O trabalho de mapear nossos processos de maneira mais genérica através do uso de hipermídia foi descrito em artigos publicados recentemente no portal da ACM.

Imaginemos agora o processo tradicional:

1. Executa uma busca
2. Adiciona o produto ao carrinho
3. Executa outra busca
4. Adiciona o produto ao carrinho
5. Paga

Em um sistema de web services clássico, onde temos diversos serviços, como o servidor me diria que devo pagar em outro sistema sem que eu precise escrever nem uma linha de código? Isso iria quebrar o meu cliente, e gerar a necessidade de codificar já pensando nessas falhas e eventuais evoluções do sistema.

Se o servidor passou a suportar somente uma determinada quantidade de produtos no seu carrinho, seu cliente quebrará pois não foi feito adapatdo a isso, o cliente REST se adapta e compra o que for possível.

Se nosso produto ou empresa utiliza esses modelos tradicionais de business process e web services e cada mudança no serviço está implicando em altos custos de mudança nos clientes, temos um grande indício de que esse modelo tradicional apresenta o alto acoplamento que uma arquitetura REST está tentando combater.

Serviços web tradicionais desacoplam um pouco mais que outras maneiras tradicionais de RPC, mas ainda mantém muito acoplamento.

Se o custo de manutenção de seu código cliente está alto, é porque seu web service te acoplou demasiadamente ao servidor e aos schemas relacionados.

A seguir você encontra um vídeo de introdução ao acoplamento que o método tradicional apresenta:

Minimizando acoplamento com REST from Caelum on Vimeo.