Restful Web 服务如何优于基于 SOAP 的 Web 服务答案

【问题标题】：how is Restful web services better than SOAP based webservicesRestful Web 服务如何优于基于 SOAP 的 Web 服务
【发布时间】：2010-11-09 19:53:22
【问题描述】：

我浏览了各种站点，他们提供的唯一答案是——Restful webservices 使用 Http 自己的方法，例如 (GET,POST,PUT,DELETE).. 而基于 SOAP 的 webservices 使用它自己的自定义方法。 . - Restful Web 服务将每个服务方法视为一种资源，并给它一个 URI..

但是我不明白这些答案的全部意义。至于为什么这些东西被证明比基于 SOAP 的 Web 服务具有如此大的优势。

一个例子将不胜感激

【问题讨论】：

可能重复：stackoverflow.com/questions/76595/soap-or-rest
你有什么想法吗？你有 4 个很好的答案。
@RPM1984: 是的，我想我会选择 REST，因为它具有不同服务的不同 URL，这使得它非常松散耦合，并且还具有类似 url 结构的目录（不像 SOAP 具有“www.somesite .com?query=something") 这使它对搜索引擎友好。 :)

标签： java rest soap service

【解决方案1】：

REST 自然适合 Web/Cloud API，而 SOAP 适合分布式计算场景。

带宽是 REST 的主要优势，因为不需要遍历复杂的文档（即 XML、SOAP 标头），这对于良好执行 Web API 极为重要。 JSON 是一种被广泛认可且简单的数据交换标准，并且很容易被浏览器和客户端代码读取，这就是为什么大多数 RESTful API（雅虎就是一个很好的例子）都提供 JSON 的原因。

更不用说 REST 可用于 XmlHttpRequest 对象，这对于 Web API 的 AJAX 能力同样至关重要。

当然，REST 的可缓存性特性也不容忽视。因为 REST 基于 HTTP，它可以利用 HTTP（以及 Web 本身）的许多语义，通过利用 HTTP 数据包（过期）上的标头来启用浏览器的缓存。更不用说像 gzip 压缩这样的东西来提高效率了。在性能方面，REST 确实优于 SOAP。

对于 SOAP，SOAP 适合有状态的操作。 WS* 标准（安全、事务等）处理这种在分布式场景中很常见的管道。当然，它可以用 REST 来完成，但它就不是真正的 REST。 SOAP 非常适合定义客户端和服务器之间的操作契约，这在分布式场景中至关重要。

所以我的意见（整个 SOAP 与 REST 的事情是高度固执己见的），将 SOAP 用于分布式计算场景，将 REST 用于 Web API。

【讨论】：

@RPM1984：“REST 的可缓存性特性”是什么意思？
@user384706 - 因为 REST 基于 HTTP，它允许在响应中添加缓存标头（过期），以便它们可以被浏览器缓存。响应数据包明确声明了可缓存性。现在这是 client 缓存，不要与服务器缓存混淆。这也是为什么我的主要帖子是 REST for Web，SOAP for Distributed Computing。
我使用 REST 进行分布式计算。非常适合各种场景。
@RPM1984：好的，但为什么这只适用于 REST？ SOAP 消息通过 HTTP 传输。如果它们的 msg 是 SOAP，也可以应用缓存。对吗？
@Darrel Miller - 这就是为什么我的最后一段有警告“所以我的意见”。 :) REST 与 SOAP 的争论高度。我曾在后端系统与 15 多个其他系统集成的公司工作过。他们在这里选择了 SOAP，因为最重要的是操作契约/安全性，而不是性能/可扩展性。正如我所说，这是我的意见/经验。我自己是一个 RESTful 的小男孩。 :)

【解决方案2】：

SOAP 的主要问题是臃肿。你能做的越多，你能使用的默认值就越少。即使对于简单的方法，这也会导致大量 WSDL 下载。接下来，它会膨胀解析器（特定解析器总是小于通用解析器）、消息（一大堆 XML 而不是带有 URI 的 DELETE）、错误处理程序（您向服务器发送 20-30KB 的 XML它会以 50KB 的错误消息进行响应；祝您阅读并理解它。

具体示例：通过 SOAP 从 SharePoint 服务器读取文档列表的 Java 代码非常庞大，您需要为 Java 编译器提供 1GB 的 RAM 来编译它。

Restful 也一样，只需要几行代码。在客户端，您需要使用GET list/some/url 构建请求。即使您必须手动编写代码，在服务器上解析它也会比编译 WSDL 更省力。

【讨论】：

从它的声音来看，您对框架的体验非常糟糕。 SOAP 通常比 REST 需要更少的手动编码来开始，因为框架通常会自动化大部分管道。 WSDL 的大小应该与运行时性能无关，因为它仅用于协助客户端代理生成。
我使用了 Axis。 Java 上还有其他内容吗？此外，WSDL 的大小也很重要，因为大 WSDL == 大请求。

【解决方案3】：

许多人不赞成基于 SOAP 的 Web 服务，因为 SOAP 层增加了额外的复杂性，认为这是一种过度的开销，因此提出了 RESTful Web 服务。
在 REST 框架中，xml 消息直接封装在 HTTP 负载中，而不是封装在 SOAP 信封中（与 AJAX 相同）。
这大大减少了解析开销。
但在实际情况下，通常需要向服务器/客户端发送与实际 xml 消息有效负载无关的额外信息。
这导致找到通过 HTTP 消息传输信息的方法。
由于需要传输此类信息，一些人反驳说基于 SOAP 的服务有助于满足这些需求。

【讨论】：

【解决方案4】：

优势是战术性的——它当然可以做你能做的所有事情，但是网络服务器在 SOAP 之前就已经出现了，而且配置起来相当简单，因此通常更简单。例如，身份验证等通常可以由网络服务器处理，重定向和负载平衡等也可以。普通的 SOAP 框架并没有真正拥有完整的一组这样的东西，并且可能会导致成长的痛苦。

【讨论】：