今天参加了一个关于REST的有趣演示，但是，我想不出一个原因（也没有提到）为什么REST比基于SOAP的服务堆栈更好或更简单地使用和实现。
为什么“真实世界”中的任何人使用REST而不是基于SOAP的服务？
答案 0 :(得分：156)
开销减少（没有包装每个调用的SOAP信封）
减少重复（HTTP已经表示DELETE，PUT，GET等操作，否则必须在SOAP信封中表示）。
更加标准化 - HTTP操作得到很好的理解并且运行一致。一些SOAP实现可能会很糟糕。
更具人性化和可测试性（仅使用浏览器更难测试SOAP）。
不需要使用XML（你也不需要使用SOAP，但它很难理解，因为你已经在解析信封了。）
图书馆使SOAP（有点）容易。但是正如我所指出的那样，你正在抽象出很多冗余。理论上是的，SOAP可以覆盖其他传输，以避免在一层做类似的事情，但实际上几乎所有的SOAP工作都是通过HTTP进行的。
答案 1 :(得分：35)
RESTful服务比基于SOAP的（常规）服务更容易使用。这样做的原因是REST基于正常的HTTP请求，这使得意图可以从正在进行的请求类型推断（GET = retrive，POST = write，DELETE = remove等等），并且完全是无状态的。另一方面，你可以说它不太灵活，因为它消除了包含请求上下文的消息信封的概念。
根据我的经验，SOAP是企业内部服务的首选，而REST则是公共API公开的服务的首选。
使用像.NET框架中的WCF这样的工具，将服务实现为REST或SOAP是非常简单的。
一些相关的阅读：
答案 2 :(得分：12)
我假设当你说“web服务”时你指的是SOAP和WS- *标准集。 （否则，我可以说REST服务是“Web服务”。）
规范论证是REST服务与Web设计更接近 - 即HTTP和相关基础架构的设计。因此，使用REST服务将与现有的Web工具和技术更加兼容。
当然，一旦您深入研究细节，您会发现这两种方法在不同情况下都具有优势。是你感兴趣的那些细节吗？
答案 3 :(得分：9)
开销并不像良好的架构那么重要。
REST不是一种协议，它是一种鼓励良好可扩展设计的架构。 通常选择它是因为RPC过多的自由度很容易导致设计不良。
另一个原因是基于HTTP的RESTful协议的可预测成本，因为它可以利用现有技术（主要是代理）。 RPC的初始成本非常低，但随着负载的增加，它往往会显着增加。
答案 4 :(得分：6)
在这个主题上阅读Roy Fielding最优秀的dissertation。他做了一个很好的案例，并且在他写作（2000）之前绝对是 WAY 。
答案 5 :(得分：6)
REST与实现无关且更加透明，这使得它非常适合公共API，特别是对于像Flickr，Amazon或Digg这样使用其API作为营销工具并且真正希望人们使用其数据的大型网站。他们不希望成为那些试图调试他们选择的错误SOAP库的脚本语言的新手开发人员的手持。
与SOAP和WSDL相比，它们更适合内部应用程序，在这些应用程序中，您可以使用嵌入式库和两端已知的知名人员。 （并且您可能不必关心诸如因特网规模的负载平衡，HTTP缓存等等。）然后，您将获得自我记录的API，保留类型等，无需工作。
答案 6 :(得分：5)
Steve Vinoski's blog和他的latest articles绝对值得一试。他是前CORBA大师，他与Michi Henning撰写了关于这一主题的最佳书籍"Advanced CORBA® Programming with C++"。但是，他已经看到了他的客户端/服务器方式的错误，现在发誓REST。
答案 7 :(得分：4)
REST允许您的非变异操作（通常使用GET动词）缓存。也就是说，由客户端缓存和/或由代理缓存。这可能是一个巨大的胜利！
答案 8 :(得分：2)
REST基本上只是一种实现Web服务的方法。它只是一种正确使用HTTP来查询您尝试访问的Web服务的方法。
http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer
答案 9 :(得分：0)
超级简单而纤细。您可以通过http动词：GET使用浏览器。 我没有找到一个浏览器可以轻松手动执行通用的http POST请求
答案 10 :(得分：0)
以下是一个数据点：亚马逊提供REST和SOAP格式的API，其中85％的用途是REST。
REST更容易实现，更易于理解和更高的性能。