RESTful or not RESTful?

  • Article

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 https://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?