为什么会使用REST而不是基于SOAP的服务？
今天在REST上有一个有趣的演示，但是，我想不出一个理由（也没有人提出），为什么REST在使用和实现方面比基于SOAP的服务栈更好或更简单。
什么是“真实世界”中的任何人使用REST而不是基于SOAP的服务的一些原因？
较less的开销（没有SOAP信封来包装每个呼叫）
减less重复（HTTP已经表示像DELETE，PUT，GET等操作，否则必须在SOAP信封中表示）。
更加标准化 – HTTP操作是很好的理解和操作一致。 一些SOAP实现可能会非常挑剔。
更多的人类可读性和可testing性（很难用浏览器来testingSOAP）。
不需要使用XML（你也可以不必使用SOAP，但是因为你已经在parsing信封了，所以很难理解）。
图书馆使SOAP（一种）变得简单。 但是正如我所指出的那样，你正在抽象出很多冗余。 是理论上SOAP可以超越其他的传输，以避免在类似的事情上层层叠叠，但实际上几乎所有的SOAP工作都是通过HTTP进行的。
REST式服务比基于SOAP （常规）服务要简单得多。 原因是REST基于正常的HTTP请求，它使得能够根据正在进行的请求types（GET = retrive，POST = write，DELETE = remove等等）来推断意图，并且是完全无状态的。 另一方面，你可能会认为它不够灵活，因为它消除了包含请求上下文的消息信封的概念。
根据我的经验，SOAP一直是企业内的服务的首选，而REST一直被作为公开API公开的服务。
在.NET框架中使用类似WCF的工具，将服务作为REST或SOAP实现是非常简单的。
一些相关的阅读：
- amazon web services博客：REST vs SOAP
- 敢于经常写关于REST的奥巴桑乔
我假定当你说“Web服务”时，你的意思是SOAP和WS- *标准。 （否则，我可以争辩说，REST服务是 “networking服务”。）
规范的观点是，REST服务与Webdevise（即HTTP和相关基础设施的devise）更接近。 因此，使用REST服务将与现有的networking工具和技术更加兼容。
当然，一旦你深入细节，你会发现这两种方法在不同情况下都有优势。 这些是你感兴趣的细节吗？
开销并不像build筑一样重要。
REST不是一个协议，它是一个鼓励良好可扩展devise的体系结构。 通常select它是因为RPC中的自由度过大容易导致devise不佳。
另一个原因是HTTP上RESTful协议的可预测成本，因为它可以利用现有技术（主要是代理）。 RPC初始成本相当低，但随着负荷强化，其成本往往会大幅上升。
REST与实现无关，透明度更高，这对公共API尤其如此，尤其是像Flickr，Amazon或Digg这样的大型网站，它们将API作为营销工具，真正希望人们消费他们的数据。 他们不希望手持1000多名试图debugging他们的脚本语言select的错误的SOAP库的新手开发人员。
与SOAP和WSDL相比，它们更适合内部应用程序，在这些应用程序中，您可以使用embedded式库和知名人员。 （你可能不需要关心像Internet负载平衡，HTTPcaching等等）。然后你得到的API是自我logging的，保存types等零工作。
阅读Roy Fielding关于这个话题的最优秀的论文 。 他做了一个很好的例子，当他写这本书的时候（2000年）肯定是在他的时代之前。
Steve Vinoski的博客和他的最新文章绝对值得一读。 他是一名前CORBA大师，可能是Michi Henning撰写的“用C ++进行高级CORBA编程”的最好的书。 不过，他已经看到了他的客户/服务器方式的错误，现在又被REST发誓。
REST允许caching你的非变异操作（通常使用GET动词）。 也就是说，由客户端caching和/或由代理caching。 这可能是一个巨大的胜利！
REST基本上只是实现Web服务的一种方式。 这只是正确使用HTTP来查询您尝试访问的Web服务的一种方式。
http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer
这是超级简单，苗条。 你可以用浏览器通过http动词：GET。 我没有find一个浏览器可以轻松地手动做通用的HTTP POST请求
以下是一个数据点：Amazon提供REST和SOAP格式的API，其中85％是REST。
REST更容易实现，更容易理解和更高的性能。
