Restful Web服务如何比基于SOAP的Web服务更好
我已经浏览了各种网站，他们提供的唯一答案是 – Restful webservices使用Http自己的方法，如（GET，POST，PUT，DELETE）..而基于SOAP的webservices使用自己的自定义方法.. – Restful Web服务将每个服务方法视为资源并为其提供URI。
但是我不明白这些答案的全部意义。至于为什么这些事情certificate比基于SOAP的Web服务有如此大的优势..
一个例子将不胜感激
REST自然适用于Web / Cloud API，而SOAP适用于分布式计算方案。
带宽是REST的主要优点，因为没有复杂的文档可以遍历（即XML，SOAP标头），这对于性能良好的Web API非常重要。 JSON是一种广泛认可且简单的数据交换标准，并且易于被浏览器和客户端代码读取，这就是为什么大多数RESTful API（雅虎都是一个很好的例子）提供JSON的原因。
更不用说REST可用于XmlHttpRequest对象，这对于Web API的AJAX能力也是至关重要的。
当然，REST的可缓存性function也不容忽视。 因为REST基于HTTP，所以它可以利用HTTP（和Web本身）的许多语义，通过利用HTTP数据包（过期）上的标头来启用浏览器的缓存。 更不用说像gzip压缩这样的东西来提高效率。 性能方面，REST确实将它钉在SOAP上。
至于SOAP，well SOAP适用于有状态操作。 WS *标准（安全性，事务等）处理这种管道，这在分布式场景中非常常见。 当然，它可以通过REST来完成，但它确实不是REST。 SOAP非常适合在客户端和服务器之间定义操作契约，这在分布式场景中至关重要。
所以我的观点（以及整个SOAP vs REST的事情都是高度自以为是），将SOAP用于分布式计算场景，将REST用于Web API。
SOAP的主要问题是膨胀。 您可以做的越多，使用默认值就越少。 即使对于简单的方法，这也会导致巨大的WSDL下载。 接下来，它使解析器膨胀（特定解析器总是小于通用解析器），消息（整个一堆XML而不是带有URI的DELETE ），error handling程序（你向服务器发送20-30KB的XML，它以50KB的错误消息回复;祝你好运阅读并理解它）。
具体示例：通过SOAP从SharePoint服务器读取文档列表的Java代码非常庞大，您需要为Java编译器提供1GB的RAM来编译它。
与Restful相同只需要几行代码。 在客户端上，您需要使用GET list/some/url构建请求。 即使您必须手动编写代码，在服务器上解析它也会比编译WSDL更省力。
许多人不赞成基于SOAP的Web服务，因为SOAP层增加了额外的复杂性，将其视为过度开销，提出了RESTful Web服务。
在REST框架中，xml消息直接封装在HTTP有效负载中，而不是封装在SOAP信封内（与AJAX相同）。
这大大减少了解析开销。
但在实际情况下，经常需要向服务器/客户端发送与实际xml消息有效负载无关的额外信息。
这导致找到通过HTTP消息传输信息的方法。
由于需要传输此类信息，因此有些人反驳说基于SOAP的服务可以满足这些需求。
优点是战术 – 它当然可以完成你可以用另一个做的所有事情，但是web服务器在SOAP之前就已经存在并且配置相当简单，因此通常更简单。 例如，身份validation等通常可以由Web服务器处理，也可以重定向和负载平衡和事物。 普通的SOAP框架实际上并没有像完整的一组这样的东西，并且可能导致成长的痛苦。