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:
- Executa uma busca
- Adiciona o produto ao carrinho
- Executa outra busca
- Adiciona o produto ao carrinho
- 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.