Minha arquitetura dói. Devo mudar para REST?

6 de maio de 2010

O que perdemos em não chegar em uma arquitetura REST de verdade, mas nos manter no modelo tradicional que adotamos até então?

Menor acoplamento

Em arquiteturas tradicionais, incluindo as típicas implementações de web services encontradas em clientes, temos um servidor com forte acoplamento a contratos (schemas e infinitos verbos) que inibem a evolucão de seu servidor independente de seu cliente, o que chamamos de forward-compatibility.

A arquitetura que apliquei é REST?

Um sinal que mostra a não adoção de um arquitetura REST é a existência de forte acoplamento entre clientes e servidores. Na arquitetura que está analisando, as mudanças no servidor implicam em alterações em seus clientes? Eles devem baixar código fonte (jar, gems etc)? Recompilar os projetos?

Mais genericamente, se a api disponibiliza um jar, gem ou equivalente que é sua API cliente, seu coupling é maior do que um sistema REST real.

Qualquer mudança em todos os clientes, mesmo os que não utilizam as novas funcionalidades, é um acoplamento indesejado. Imagine se todos os usuários do paypal devessem atualizar seus sistemas a cada novo release de sua API?

Se no cenária atual, os custos de manutenção estão altos pois toda mudança é refletida em manter clientes atualizados, sua aplicação claramente não é REST.

Em REST, forward-compatibility é natural.

Escalabilidade

O conceito de REST tenta pegar o que levou a web a ser esse mundo onde aplicações são criadas, alteradas e os clientes (seres humanos) continuam funcionando. É um ótimo da adaptabilidade de aplicações distribuídas como as conhecemos hoje. Não são web services educados.

Se sua empresa sofre com o alto acoplamento que web services popularizados criaram, com altíssimos custos de manutenção, ou ainda baixa escalabilidade, REST de verdade pode ser a solução.

Pergunta/Resposta

As abordagens de web services, SOA como praticado pelo mercado, EJB, RMI, Corba e RPC possuem características similares de alto acoplamento. Responda o questionário a seguir para analisar a vantagem de se usar REST:

(RPC) Qual a facilidade de colocar coisas novas e alterar servidores
existentes na sua arquitetura atual e não
encostar em nenhum cliente, tudo continuando a funcionar como antes? Seu cliente continua funcionando?

(RPC) Você consegue escalar para níveis como o da web, sem precisar comprar produtos de middleware, usando somente middleware commodity como proxies?

(RPC) Quantas vezes a api que você acessava (i.e. amazon) mudou e deixou seu programar quebrar?
(REST) Quantas vezes a amazon mudou o site e você não conseguiu comprar algo?

(RPC) Quantas vezes o sistema do correios ficou fora do ar e seu sistema não resolveu o problema de tolerância a falha, impedindo fornecer cotações de envio de produtos?
(REST): E se a estimativa continuasse válida, sem ter que alterar uma linha de código?

(RPC): Toda vez que sua API muda, você lança uma versão nova e obriga seus clientes a baixarem.
(REST): Você lança uma versão nova.

(RPC): Ao mudar a estrutura de seus recursos – como relacionamentos – todos os clientes quebram. O cliente, frágil, quebra facilmente.
(REST): O cliente, robusto, se adapta as necessidades e permite alterações no recurso e no meio que ele é representado.

Se você deseja alcançar essa arquitetura, é necessário executar diversos passos e usar REST como um todo, não somente verbos http e URIs.

– Se você deseja clientes acessando seu sistema durante anos, sem ter que atualizar todos os sistemas satélites mensalmente.

– Se você deseja escalar sem session replication.

– Se você deseja trabalhar com blue green deployment

– Se você quer ensinar clientes a funcionar com código que eles jamais viram na vida

Adotando REST

Tenho publicado uma série de artigos e vídeos em como adotar REST na prática, do zero.

Artigos técnicos que mostram os problemas e a maneira de implementar uma aplicação REST.

Antes disso, é vital mudar a maneira de pensar de arquiteturas RPC – como serviços web tradicionais – e para isso, é necessário um trabalho mais arquitetural com seus desenvolvedores.

Ao mesmo tempo, um trabalho gerencial permite encontrar os pontos de suas aplicações que se beneficiriam imediatamente, potencializando o retorno do investimento nessa arquitetura.

Eventos

Nesse ano de 2010 são diversos os eventos onde apresentaremos essas vantagens e como migrar para tal plataforma.

Seja em um evento sobre REST, Agile ou email, sinta-se a vontade para conversar sobre o assunto.

06 de maio – Gerenciamento ágil de projetos de Software com Scrum, USCS
13 de maio – Rest do zero, na Caelum
15 de Maio de 2010 – O papel do REST no CouchDB e Neo4J- NoSQLBR
22 de maio – Deploy contínuo – pois integração contínua não basta – Maré de agilidade/Belo Horizonte
29 de maio – Um produto em duas semanas – Maré de Agilidade/Vitória

Anúncios

2 Respostas to “Minha arquitetura dói. Devo mudar para REST?”


  1. […] RSS Feed: agile « Minha arquitetura dói. Devo mudar para REST? […]


  2. […] notícias: Minha arquitetura dói. Devo mudar para REST? Arquitetura REST e o serviço Web […]


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: