为什么要使用REST而不是基于SOAP的服务？[关闭]

今天参加了有关REST的一个有趣的演示，但是，我想不出一个单独的原因（也没有一个人提出），为​​什么REST比基于SOAP的服务栈更好或更简单地使用和实现。

为什么“现实世界”中的任何人都使用REST而不是基于SOAP的服务的原因有哪些？

更少的开销（无需SOAP信封即可封装每个调用）

更少的重复（HTTP已经代表了DELETE，PUT，GET等操作，这些操作否则必须以SOAP信封形式表示）。

更加标准化-HTTP操作已广为人知，并且操作一致。某些SOAP实现可能很挑剔。

更具人类可读性和可测试性（仅使用浏览器很难测试SOAP）。

不需要使用XML（嗯，您也不必使用SOAP，但是由于您已经在解析信封，因此几乎没有意义）。

库使SOAP（种类繁多）变得容易。但是，正如我所指出的，您在下面提取了很多冗余。是的，从理论上讲，SOAP可以遍历其他传输，从而避免在做类似事情的层次上扎根，但实际上，您要做的几乎所有SOAP工作都是通过HTTP。

RESTful服务比基于SOAP的（常规）服务更容易使用。原因是REST基于正常的HTTP请求，可以从发出的请求类型（GET =检索，POST =写，DELETE =删除等）中推断出意图，并且它是完全无状态的。另一方面，您可能会争辩说它不那么灵活，因为它取消了包含请求上下文的消息信封的概念。

以我的经验，SOAP被首选用于企业内的服务，而REST被首选作为公开API公开的服务。

使用.NET框架中的WCF之类的工具，将服务实现为REST或SOAP非常简单。

一些相关的读物：

• 亚马逊网络服务博客：REST与SOAP
• Dare Obasanjo经常撰写有关REST的文章

我假设当您说“ Web服务”时，是指SOAP和WS- *标准集。（否则，我可能会认为REST服务是 “ Web服务”。）

规范的论点是，REST服务与Web设计（即HTTP和相关基础结构的设计）更接近。因此，使用REST服务将与现有的Web工具和技术更加兼容。

当然，一旦深入研究细节，就会发现两种方法在不同情况下都有优势。您感兴趣的是这些细节吗？

开销并不像好的架构那么重要。

REST不是协议，它是鼓励良好可扩展设计的体系结构。之所以选择它，是因为RPC中的自由度过高容易导致设计不佳。

另一个原因是基于HTTP的RESTful协议的可预测成本，因为它可以利用现有技术（主要是代理）。RPC的初始成本非常低，但是随着负载的增加，它往往会显着增加。

REST与实现无关，并且更加透明，这使得它非常适合公共API，尤其是对于像Flickr，Amazon或Digg这样的大型网站，这些网站都将其API用作营销工具，并且确实希望人们使用其数据。他们并不想成为开发新手的手拿着1000谁试图调试选择的越野车SOAP库的脚本语言。

与SOAP和WSDL比较，SOAP和WSDL更适合内部应用程序，因为在内部应用程序中您都有嵌入式库和两端都有知名的人。（而且，您可能不必关心Internet规模的负载平衡，HTTP缓存等。）然后，您将获得自记录的API，以零工作量保存类型等。

阅读了Roy Fielding 关于该主题的最优秀论文。他让一个优秀的情况下，是绝对WAY领先的时候，他写了他的时间（2000年）。

史蒂夫·维诺斯基（Steve Vinoski）的博客及其最新文章绝对值得细读。他是CORBA的前任大师，他可能与Michi Henning一起撰写了关于该主题的最好的书，《用C ++进行高级CORBA®编程》。但是，从那以后，他就已经看到了他的客户端/服务器方式的错误，现在向REST发誓。

REST允许缓存您的非变异操作（通常使用GET动词）。即，由客户端缓存和/或由代理缓存。这可能是一个巨大的胜利！

REST基本上只是实现Web服务的一种方式。这只是正确使用HTTP查询您要访问的Web服务的一种方法。

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

这是超级简单和苗条。您可以通过http动词：GET使用浏览器完成此操作。我找不到浏览器可以轻松地手动执行通用的HTTP POST请求

这里是一个数据点：Amazon提供了REST和SOAP格式的API，REST的使用率为85％。

REST更易于实现，更易于理解和更高性能。