Why would one use REST instead of SOAP based services?今天参加了一个关于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 = retrive，POST = write，DELETE = remove等等)，并且完全是无状态的。另一方面，您可能会认为它不太灵活，因为它消除了包含请求上下文的消息信封的概念。 根据我的经验，SOAP是企业内部服务的首选，而REST则是公共API公开的服务的首选。 使用.NET框架中的WCF等工具，将服务实现为REST或SOAP非常简单。 一些相关的阅读：
我假设当你说"web服务"时你指的是SOAP和WS- *标准集。 (否则，我可以说REST服务是"Web服务"。) 规范性的论点是，REST服务与Web设计更为匹配 - 即HTTP和相关基础架构的设计。因此，使用REST服务将与现有的Web工具和技术更兼容。 当然，一旦您深入研究具体细节，您会发现这两种方法在不同情况下都具有优势。是你感兴趣的那些细节吗？ 作为良好的架构，开销并不重要。
REST不是一种协议，它是一种鼓励良好可扩展设计的架构。
另一个原因是基于HTTP的RESTful协议的可预测成本，因为它可以利用现有技术(主要是代理)。 REST与实现无关，而且更加透明，这使得它非常适合公共API，特别是对于像Flickr，Amazon或Digg这样使用其API作为营销工具并且真正希望人们使用其数据的大型网站。他们不想成为那些试图调试他们选择的有缺陷的SOAP库的脚本语言的新手开发人员。 与SOAP和WSDL相比，它们更适合内部应用程序，在这些应用程序中，您可以使用嵌入式库和两端已知的知名人员。 (并且您可能不必关心诸如Internet规模的负载平衡，HTTP缓存等事情。)然后您获得自我记录的API，保留类型等，零工作。 要阅读Roy Fielding关于这个主题的最优秀的论文。他做了一个很好的案例，并且绝对是在他写作的时候(2000年)。 Steve Vinoski的博客和他的最新文章绝对值得一读。他是一名前CORBA大师，他曾与Michi Henning编写了关于这一主题的最佳书籍，"高级CORBA？用C ++编程"。但是，他已经看到了他的客户端/服务器方式的错误，现在发誓REST。 REST允许缓存非变异操作(通常使用GET动词)。 也就是说，由客户端缓存和/或由代理缓存。 这可能是一个巨大的胜利！ REST基本上只是实现Web服务的一种方式。它只是一种正确使用HTTP来查询您尝试访问的Web服务的方法。
http://www.xfront.com/REST-Web-Services.html 这里有一个数据点：亚马逊提供REST和SOAP格式的API，85％的用法是REST。 REST更容易实现，更易于理解和更高的性能。
它非常简单和纤薄。您可以通过http动词：GET使用浏览器。 |
