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


153

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?


37
Por serviços web, você está se referindo a serviços web estilo SOAP? Porque, tanto quanto eu sei, você também pode ter serviços da web RESTful.
James McMahon

Respostas:


160

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.


1
Gostaria de acrescentar que a comunicação SOAP entre plataformas também pode ser uma PITA (isso não fazia parte do SOAP?!?).
Justin Bozonier 18/09/08

7
Também ótimo trabalhar com HTTP infra-estrutura - por exemplo GETs são armazenados em cache de forma agressiva, juntamente com o uso de modificada pela última vez e etags
James Strachan

Trabalhando muito com os navegadores da Web para fornecer um cliente universal para seus serviços também ajuda :)
James Strachan

2
Eu diria que o SOAP é bem padronizado. Se você quer dizer que as implementações são imaturas, convém deixar isso mais claro. Eu valorizaria algumas evidências para essa visão, caso você esteja sugerindo isso. Eu também questionaria se o REST é mais legível por humanos, isso depende inteiramente de como você escolhe formatar seu conteúdo. E lembre-se também de que o XML foi projetado para ser legível por humanos, embora seja detalhado como todos sabemos.
1111 Howard Howard

6
O HTTP é tão padronizado quanto o SOAP e existe há mais tempo, portanto as implementações são realmente estáveis ​​e interoperáveis. O SOAP também será inerentemente menos legível, mesmo com conteúdo idêntico, por causa do envelope em que o conteúdo está envolvido. Na prática, nos últimos anos, eu achei o JSON sobre HTTP a melhor combinação, apenas legível o suficiente enquanto estava sendo ainda mais compacto.
Kendall Helmstetter Gelner

36

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:


9
Meu entendimento é que os arquivos WSDL podem ser usados ​​para gerar classes para expor os métodos de serviço da web. Certamente isso torna o consumo dos serviços tão fácil quanto chamar uma função? Você pode explicar sua opinião um pouco mais, por favor.
11/05/2009 Howard

1
Howard May: Supondo que você chame funções usando apenas tipos de dados primitivos, isso certamente é verdade. Mas, nesse caso, você não pode argumentar exatamente que o SOAP é mais fácil do que descansar. Se você tiver tipos de dados complexos, o processamento WSDL poderá funcionar bem entre duas máquinas com as mesmas pilhas do WS. Mas você inevitavelmente terá problemas assim que misturar pilhas. Ele deixa de ser tão fácil assim que você precisa acessar o WSDL manualmente para depurar incompatibilidades.
31119 Joseph Holsten

1
Em 2014, quase todas as plataformas, mesmo as antigas, suportam WSDL. As classes de proxy tornam o uso da API extremamente simples. Estamos implementando um serviço de push e estou considerando o REST, mas estou realmente tendo problemas para obter algum benefício.
precisa saber é o seguinte

13

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?


10

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.


7

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.


Uma boa resposta, mas eu discordo que SOAP significa que você não pode ter balanceamento de carga na escala da Internet.
HDave

7

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).



5

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!


8
Isso é simplesmente 'usando HTTP corretamente' e não REST.
aehlke


0

É 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


1
Violinista do Google Checkout. Não é um navegador, mas é uma ótima maneira de criar POST HTTP sem código. fiddler2.com/fiddler2
Eric Schoonover

Normalmente faço isso modificando a solicitação existente com Charles. Eu também tenho o Violinista.
Ray Lu

0

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.


7
Você tem alguma referência para a sua declaração de "desempenho superior"?
James McMahon

3
Onde você conseguiu 85% de uso? Isto é muito bom saber (se eu posso ver a prova)
schmoopy

3
A leitura manual de uma especificação de API, a impressão de páginas etc. é mais fácil de implementar do que "Clique com o Botão Direito, Adicionar Referência de Serviço"? (VS2010)
BlueChippy

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.