No seu novo post, Arnon Rotem-Gal-Oz dá sua opinião sobre REST (uma discussão mais detalhada sobre REST de Arnon pode ser encontrada aqui)
De acordo com Arnon, as três maiores vantagens de usar REST são:
- Relativa facilidade de integração:
...uma boa API RESTful é encontrável a partir de sua URI inicial. Isso não quer dizer que qualquer aplicação chamando seu serviço vai automagicamente saber o que fazer. Significa, no entanto, que o desenvolvedor lendo sua API tentando integrá-la terá mais facilidade. Especialmente se a hipermidia te dá um mapa do que fazer a seguir
- Uso de padrões difundidos - HTTP é a implementação mais comum de REST:
Falando HTTP que é o protocolo da web, emitir JSON ou ATOMPub significa que é muito mais fácil achar uma biblioteca que pode conectar em você em qualquer linguagem ou plataforma.
- Escalabilidade:
...comunicação sem estados, repositórios replicados constituem um bom potencial de escalabilidade.
Arnon também discute algumas das desvantagens do REST. Na sua visão as duas maiores desvantagens do REST são:
- Implementações "Lo-rest" (usar apenas GET e POST), que são específicas de REST sobre HTTP:
Enquanto tecnicamente pode ainda ser RESTful, para mim uma interface uniforme com 2 verbos é muito pequena para ser realmente útil (o que na verdade faz muito da implementação unRESTful)
- Limitações das linguagens de programação de hoje:
... linguagens de programação não estão orientadas a recursos portanto o código que vai mapear as URIs tende a ser bagunçado. Por outro lado é relativamente difícil fazer uma API REST orientada a hiper-texto (O que é uma restrição do REST)
Finalmente, Arnon aponta os casos feios de REST, que, na sua maioria, acontecem por causa do mau uso do REST:
- Seguidores zelosos (termo usado por Arnon - prova novamente que discussões sobre REST são normalmente religiosas)
Não é algo único ao REST, toda boa tecnologia/ideia(Agile, TDD etc. ) tem sua parcela de seguidores que pensam que [insira sua ideia favorita] é a melhor coisa desde o pão fatiado e que todos deveriam fazer como eles fazem.
- Não entendimento do REST:
... construindo uma implementação que é GETsful (ou seja, faz tudo com http GET) ou fazendo RPC puro onde a URI é o comando, fazendo CRUD com verbos HTTP etc. etc.
Arnon conclui seu post dizendo que:
REST parece simples mas não é - ele requer pensar mais (por exemplo, identificar recursos, externalizar as transições de estado, etc.). ... fazendo certo pode ser uma ferramenta importante e útil na sua caixa de ferramentas. [mas] ... como qualquer arquitetura/tecnologia - uma implementação ruim pode negar todos os benefícios
Parece ser um debate sem fim de SOA sobre WS* vs. REST. Na realidade nenhum deles é a "resposta para tudo" (esteja atento para a Síndrome do "Martelo")
... quando você tem uma visão holística de um negócio completo você tende a ver lugares onde princípios de arquitetura distintos servem bem. Estilos de arquitetura (e padrões de arquitetura) são ferramentas que você pode usar para resolver os desafios. Há lugares onde um martelo serve bem, mas também é sábio que a sua caixa de ferramentas tenha mais que apenas um martelo.
Por exemplo, a maioria das implementações REST não suportam invocações e eventos assíncronos. Como resultado, o estilo de arquitetura orientado a eventos não serve para REST. Outro exemplo, a preocupação com a separação entre negócio e infra-estrutura que o o envelope SOAP providencia é deixada para quem vai implementar, no caso do REST. Consequentemente, a implementação requer um número significante de preocupações com potenciais mudanças na infra-estrutura, que podem não servir bem ao REST.
REST ganhou popularidade adicional ultimamente com os avanços na Web 2.0, especificamente Mashups e AJAX . Nete caso, serviços REST são normalmente acessados por Javascript e usam JSON como mecanismo de serialização. Baseado nisto, muitos dos proponentes do REST afirmam que REST é mais fácil de consumir comparado aos muitos padrões WS*. Bem, isso é verdade se você está implementando consumidores "na mão". Por outro lado, ferramentas que geram consumidores de serviços WSDL e que estão disponíveis em muitas linguagens de programação tornam esse trabalho trivial.
A lista de exemplos de REST vs. [qualquer coisa] não acaba e depende pesadamente do autor da lista. No seu post, Arnon apresenta um bom 'homem de palha' para escolher a arquitetura apropriada para uma implementação.