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

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

解决方案

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

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

我假设当我们说" Web服务"时，是指SOAP和WS- *标准集。 (否则，我可能会认为REST服务是" Web服务"。)

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

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

更少的开销(无需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的文章

阅读了Roy Fielding关于该主题的最优秀论文。他是一个很好的案例，并且绝对比他写作时(2000年)领先。

史蒂夫·维诺斯基(Steve Vinoski)的博客及其最新文章绝对值得细读。他是CORBA的前任大师，他可能与Michi Henning一起撰写了关于该主题的最佳书籍" Advanced CORBA？C ++ Programming"。但是，从那以后，他就看到了客户端/服务器方式的错误，现在向REST发誓。

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

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

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

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

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

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

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

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

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