Por que alguém usaria REST em vez de serviços baseados em SOAP? [fechadas]

Participei de uma demonstração interessante no REST hoje, no entanto, não consegui pensar em um único motivo (nem foi apresentado) por que o REST é de alguma maneira melhor ou mais simples de usar e implementar do que uma pilha de serviços baseada em SOAP.

Quais são algumas das razões pelas quais alguém no "mundo real" usa o REST em vez dos serviços baseados em SOAP?

Menos sobrecarga (sem envelope SOAP para encerrar todas as chamadas)

Menos duplicação (o HTTP já representa operações como DELETE, PUT, GET, etc., que precisam ser representadas em um envelope SOAP).

Mais padronizado - as operações HTTP são bem compreendidas e operam de forma consistente. Algumas implementações de SOAP podem ficar complicadas.

Mais legível e testável por humanos (mais difícil de testar o SOAP com apenas um navegador).

Não é necessário usar XML (bem, você também não precisa usar SOAP, mas isso dificilmente faz sentido, pois você já está analisando o envelope).

As bibliotecas tornaram o SOAP (mais ou menos) fácil. Mas você está abstraindo muita redundância por baixo, como observei. Sim, em teoria, o SOAP pode repassar outros transportes, para evitar que suba em uma camada fazendo coisas semelhantes, mas, na realidade, quase todo o trabalho SOAP que você fará é sobre HTTP.

Os serviços RESTful são muito mais simples de consumir do que os serviços (regulares) baseados em SOAP . A razão para isso é que o REST é baseado em solicitações HTTP normais, o que permite deduzir a intenção do tipo de solicitação que está sendo feita (GET = recuperar, POST = gravar, DELETE = remover, etc ...) e é completamente sem estado. Por outro lado, você poderia argumentar que é menos flexível, pois elimina o conceito de envelope de mensagem que contém o contexto da solicitação.

Na minha experiência, o SOAP foi preferido para serviços dentro da empresa e o REST foi preferido para serviços expostos como APIs públicas.

Com ferramentas como o WCF na estrutura .NET, é muito trivial implementar um serviço como REST ou SOAP.

Alguma leitura relevante:

• Blog da Amazon Web Services: REST vs SOAP
• Ouse Obasanjo escreve frequentemente sobre REST

Assumirei que, quando você diz "serviços da web", quer dizer SOAP e o conjunto de padrões WS- *. (Caso contrário, eu poderia argumentar que os serviços REST são "serviços da web".)

O argumento canônico é que os serviços REST são uma correspondência mais próxima ao design da Web - ou seja, o design do HTTP e da infraestrutura associada. Portanto, o uso de um serviço REST será mais compatível com as ferramentas e técnicas da web existentes.

Obviamente, depois de pesquisar detalhes, você descobre que ambas as abordagens têm pontos fortes em diferentes cenários. É nessas especificidades que você está interessado?

A sobrecarga não é tão importante quanto a boa arquitetura.

O REST não é um protocolo, é uma arquitetura que incentiva um bom design escalável. Geralmente, é escolhido porque muita liberdade no RPC pode facilmente levar a um design inadequado.

O outro motivo é o custo previsível dos protocolos RESTful sobre HTTP, pois ele pode aproveitar as tecnologias existentes (principalmente proxies). O custo inicial do RPC é bastante baixo, mas tende a aumentar significativamente com a intensificação da carga.

O REST é independente de implementação e muito mais transparente, e isso o torna ótimo para APIs públicas, especialmente para grandes sites como Flickr, Amazon ou Digg que estão usando suas APIs como ferramentas de marketing e realmente querem que as pessoas consumam seus dados. Eles não querem receber milhares de desenvolvedores iniciantes que estão tentando depurar a biblioteca SOAP de buggy da linguagem de script de sua escolha.

Versus SOAP e WSDL, que são melhores para aplicativos internos, nos quais você tem bibliotecas drop-in e pessoas conhecidas com dicas em ambas as extremidades. (E talvez você não precise se preocupar com coisas como balanceamento de carga em escala da Internet, cache HTTP etc.) Em seguida, você obtém APIs que são auto-documentadas, preservam tipos etc. com zero trabalho.

Leia a dissertação mais excelente de Roy Fielding sobre o assunto. Ele faz um excelente caso e foi definitivamente WAY frente de seu tempo quando ele escreveu (2000).

O blog de Steve Vinoski e seus artigos mais recentes valem definitivamente a pena. Ele é um ex-guru do CORBA, que escreveu provavelmente o melhor livro sobre o assunto com Michi Henning, "Advanced CORBA® Programming with C ++" . No entanto, ele já viu o erro de suas maneiras cliente / servidor e agora jura pelo REST.

O REST permite que suas operações não mutantes (que geralmente usam o verbo GET) sejam armazenadas em cache . Ou seja, em cache pelo cliente e / ou em cache por proxies. Isso pode ser uma grande vitória!

O REST é basicamente apenas uma maneira de implementar serviços da web. É apenas uma maneira de usar o HTTP corretamente para consultar os serviços da Web que você está tentando acessar.

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

É super simples e fino. Você poderia fazer isso com o navegador via verbo http: GET. Não encontrei um navegador que possa fazer manualmente solicitações HTTP POST genéricas com facilidade

Aqui está um ponto de dados: a Amazon oferece suas APIs nos formatos REST e SOAP e 85% do uso é REST.

O REST é mais fácil de implementar, mais fácil de entender e com melhor desempenho.