Posts Tagged ‘rest’

Aula aberta de REST e acessando CouchDB/NEO4j

17 de maio de 2010

Na semana passada houveram dois eventos que pude participar.

Na aula aberta de REST onde apresentei a parte técnica de implantação de processos e workflows através de REST, após a palestra do Jim Webber sobre motivações financeiras para tal arquitetura.

No sábado foi a vez do evento noSQLbr, organizado pelo Alexandre Porcelli, cheio de exemplos de uso avançados de banco de dados noSQL, onde pude mostrar como o CouchDB e o NEO4Jse beneficiam de características da arquitetura REST e como podem ser estendidos para obter mais vantagens ainda.

Os slides de ambos os eventos já estão no slideshare, rest
e arquitetura contemporanea com nosql via rest.

O feedback foi ótimo e semana que vem nos vemos em Belo Horizonte.

E o Luca Bastos finaliza: “A apresentação do Jim foi uma das melhores ou provavelmente a melhor que já assisti de REST. E a do Guilherm também foi incrível porque chamou a atenção para coisas muito importantes e ainda apresentou exemplos muito legais que ainda estou digerindo. ”

E você já economizou seus milhares de reais desse ano e passou a usar a web como sua plataforma?

Anúncios

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

REST a partir do zero

29 de abril de 2010

Esse é o primeiro post em uma série mostrando como usar Rails e Restfulie no servidor e Restfulie e Mikyung no cliente para criar uma arquitetura REST.

Nesse primeiro vídeo de 10 minutos você aprende a implementar em uma linha de código do Restfulie diversas representações (xml, json, atom) no servidor e também com uma linha, a enviar, receber, atualizar etc dados a partir do cliente.

Nos próximos vídeos sairemos do nível 1 do modelo de maturidade de uma arquitetura REST e passaremos para sistemas completamente REST.

Quaisquer dúvidas, junte-se ao nosso mailing list ou fale comigo no twitter.

Aplicando REST a corporações

26 de abril de 2010

Esse post é uma tradução do meu post original em inglês.

REST é o resultado de uma pesquisa que nos deixou com uma pergunta em aberto, como seu pesquisador sugeriu: REST resolve diversos problemas, mas como aplicá-lo a problemas modernos existentes em aplicações corporativas?

Aplicando REST

Após diversas conversas, resumi um modelo, derivado das restrições de REST, que nos permite medir como um sistema completo (cliente e servidor) alcança uma arquitetura REST.

O vídeo a seguir mostra um exemplo de como começar com o que acreditamos ser REST mas na verdade é uma arquitetura não REST típica e, adotando cada restrição, criar um sistema REST que executa processos de compra em quaisquer servidores REST.

O vídeo está em inglês e, em breve, postarei um tutorial do zero de como criar cliente e servidor aqui.

Qual o poder de “REST Applied”?

“REST Applied” como exemplifiquei resolve diversas preocupações modernas, preenchendo o buraco entre a dissertação de Roy e o uso da teoria em nossos problemas, abrindo espaço para um novo mundo de possibilidades.

Da mesma maneira que idéias REST, apesar de não serem chamadas de REST até então, permitiram que o crawling web fosse um cliente fantástico, “REST Applied” pode mudar a maneira como nossas aplicações se comunicam.

E por que não vimos isso antes? Pois a descrição do Roy segue o rumo de exemplos de crawling, que se beneficiam diretamente de content type negotiation. Por exemplo, o google utiliza o mesmo recurso, acessado por uma URI, com diversas línguas, podendo classificá-lo melhor do que se ficassem em URIs diferentes (sem um header adequado).

“In fact, the application details are hidden from the server by the generic connector interface, and thus a user agent could equally be an automated robot performing information retrieval for an indexing service, a personal agent looking for data that matches certain criteria, or a maintenance spider busy patrolling the information for broken references or modified content [39].”

Mas, “Not surprisingly, this exactly matches the user interface of a hypermedia browser. “… o cliente adapte-se para a representação atual, limitado a inteligência do cliente.

REST Applied pega todas essas idéias e resolve nosso problema, como os exemplos de Rest in Practice também seguem.

Frameworks/bibliotecas usadas

Restfulie dá mais suporte HTTP para bibliotecas http e provê um framework REST enquanto Mikyung permite criar seus clientes REST. Com ambos frameworks você está pronto para aplicar REST de verdade em seus problemas corporativos, não só webbies.

Mikyung significa “capital da beleza”, no sentido de “centro principal da beleza”, em coreano e é uma tentativa de reproduzir em seu nome a aparência de um belo cliente REST, comparado com código RPC.

Modelo de maturidade REST

20 de abril de 2010

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 Model

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.

Videos sobre REST

13 de abril de 2010

Nesse sábado acompanhar o encontro do GURU-SP e foi possível fazer uma apresentação relampago que o Fernando Ribeiro gravou. A palestra é a jato, portanto perdão por ser direto ao ponto.

no vídeo a seguir, faço uma apresentação em inglês sobre o que é e o que não é REST, em inglês.

E a apresentação no GURU-SP:

E você, já estava escrevendo clientes REST?

Filtros REST em Rails e Java

18 de março de 2010

Para aqueles que gostariam de ver somente o conteúdo relativo as notícias de gerenciamento ágil, assinem o feed da categoria agile.

Para quem gostaria de assinar o feed completo, utilize o feed principal.

Muitas aplicações web possuem páginas de relatórios com campos para filtragem. O exemplo mais famoso é o caso onde o usuário pode configurar a data inicial e final para filtragem de dados.

FIltragem de dados

Mas o que acontece quando o usuário clica em qualquer link desse relatório, ou de relatórios consecutivos que aparecem após o mesmo? A data se perde. Em situações genéricas, o filtro se perde.

Vou exemplificar três maneiras de implementar tal funcionalidade.

Armazenar na sessão

É muito comum ver aplicações onde na primeira tela somos responsáveis por escolher, por exemplo, com qual unidade, centro de custo ou contrato desejamos trabalhar e, a partir de então, com tal valor armazenado na sessão no lado do servidor, temos acesso a URIs como http://www.projeto.com.br/clientes que retornaria a lista de clientes de uma unidade.

O que acontece se desejo trabalhar com clientes de duas unidades ao mesmo tempo, em abas distintas? Tenho que mudar de unidade a cada clique que executo com clientes de unidades diferentes.

Além disso, caches públicos como proxies entre o servidor e o cliente não terão o mesmo ganho de desempenho com URIs identificadoras de recursos reais.

O load-balancing também se torna custoso pois a sessão fica presa a uma máquina ou deve ser replicada em determinados momentos.

Tudo isso acontece pois sua aplicação é stateful, quebrando uma das regras da arquitetura REST.

O escopo flash é uma solução que cai nessa categoria.

Parâmetros do request

Outra solução é quando as características do filtro são passadas por parâmetros em uma URI do acessada através de GET.

parametros get

Nesse caso, podemos sobrescrever o método utilizado para definição de links para sempre adicionar os parâmetros de filtagem (url-rewriting):


  # remembers the starting and end date on all links
  def url_for(options = {})
    options[:start_date] = params[:start_date]
    options[:end_date] = params[:end_date]
    super(options)
  end

  public String urlFor(Class resource, String method) {
     return "/" + resource.getName() + "&start_date=" + params("start_date") + ...;
  }

Note que em ambos os casos é possível criar um componente que decide se o parâmetro de filtragem deve ou não ser adicionado.

Com um único método (monkey patch no Rails ou definição de tag no Java) somos capazes de resolver o problema em todos os links de um sistema.

Note que com essa abordagem, não existem os problemas de sessão apresentados anteriormente.

Armazenar um cookie no client

Aqui, como na solução baseada em sessões, existe o problema do trabalho em unidades distintas em diversas abas.

Uma vez que o cookie registrou informações relativas ao estado do cliente no processo definido no servidor, as próximas requisições irão levar em consideração tal informação, em todas as abas.

Novamente perdemos escalabilidade e, se usado em conjunto com sessões, temos um fator a mais negativo no load balancing.

REST

A segunda solução é a única que se aproxima mais de uma arquitetura REST: o servidor não mantém estado e a URI identifica um recurso, onde, por exemplo, open search pode ser utilizado para o sistema de filtragem.

O segredo está em deixar o cliente através de recursos identificados por URIs, ser guiado pelo servidor, e nenhum dos dois armazenem informações relativas ao estado atual de um processo. Os recursos e seus links ditam o processo (HATEOAS).

Note que de todas as soluções, ela foi a mais simples de trabalhar e com mais vantagens.

Além disso, não foram usados cookies que quebram a transparência para layers intermediários.

Fuja de cookies e de sessões, viva uma vida mais rest.