RESTful or not RESTful?


O uso do REST acabou criando um estilo arquitetural para construir serviços.


Seus princípios são simples:



  • A web é um grafo de recursos ligados;

  • Recursos são identificados por uri’s;

  • O acesso aos recursos são feitos através dos verbos do http/https – GET, PUT, DELETE e POST;

Por que os verbos do http/https? Simples: esta é a estrutura da World Wide Web. Isto é um fato.



  • GET é para leitura e não modifica nunca o dado – o que é excelente para caching.

  • GET, DELETE e PUT devem ser usados como verbos idempotentes (isto é, a repetição destes comandos não afeta o resultado pois, ao final, tudo se passa como se tivessem sido executados uma única vez).

O que passamos ou recebemos num comando? Recursos em um de seus vários formatos: XML, RSS/Atom, XHTML, JSON ou outro.


O que há de mais estranho para quem é do mundo dos middlewares ? No mundo RESTful TUDO é uri! Ao contrário do SOAP (comum em WebServices), na arquitetura RESTful não existe nome de ações e seus parâmetros. Se quero, por exemplo, o mapa de uma certa posição do globo numa certa extensão eu teria uma uri como http://meusite/mapa/0/5/10/ (onde 0 é o valor da latitude, 5 da longitude e 10km para extensão da imagem).


Isto modifica muito a forma de desenhar um serviço? Não. Exige apenas maior cuidado com a regra de formação de nomes (de uma uri). O WCF é um exemplo de quão pequena é esta mudança. Nele (WCF) mapeamos argumentos de operações com uri’s da seguinte forma:



[OperationContract]



[WebGet(UriTemplate=“product/{productId}")]



Product GetProduct(int productId);


Assim, a expressão “{productId}” no atributo WebGet mapeia a última parte da uri com o parâmetro do método GetProduct. WebGet implica, naturalmente, o uso de um comando GET.


O que ganhamos usando a arquitetura RESTfull? Três pontos me parecem os principais:



  • usamos melhor a estrutura da web (caching e comandos do http/https );

  • tornamos todos os dados visíveis para crawlers e spiders;

  • podemos usar formatações menos pesadas para passar dados (como o JSON).

O que perdemos? Vários aspectos interessantes do WebService, como seus aspectos de segurança, federação, tipagem forte, etc.


Quando usamos um ou outro? O tempo irá dizer, mas como o REST tem tido uma boa recepção na web devido a sua simplicidade e economia, o uso da arquitetura RESTful tende também a crescer, principalmente em casos de API’s Webs abertas (pense Live, Facebook e outros). O SOAP parece ter seu gueto nas aplicações que necessitam de mais segurança, como interfaces entre aplicações corporativas através da Web.


As discussões sobre qual é o melhor estilo para construir serviços na Web me lembra em muito as discussões às vezes religiosas sobre o dilema entre linguagens interpretadas (como Ruby, JScript ou Smalltalk) e compiladas (C++, VB, Java ou C#). No fim, acabamos usando ambos os estilos.


Como arquitetos nós estamos sempre envolvidos em dilemas. Não seria diferente aqui, certo?

Comments (1)
  1. Ontem foi anunciado que o CTP1 do ADO.NET Data Services v1.5 (antes conhecido como Astoria) está a caminho!

Comments are closed.

Skip to main content