RESTful 与基于 SOAP 的 Web 服务？答案

【问题标题】：RESTful vs SOAP based webservices?RESTful 与基于 SOAP 的 Web 服务？
【发布时间】：2013-07-14 04:59:25
【问题描述】：

朋友们，我最近阅读了涵盖基于 SOAP 的 Web 服务和 RESTful Web 服务的 Web 服务书籍。我不确定应该选择哪些参数，因为它们看起来很相似（即使从开发人员的角度来看）。这是我的观点

在 SOAP Web 服务中，我们使用从 Web 服务生成的 WSDL 文件，然后基于该文件创建客户端存根。

我的理解是内部存根也将使用 HTTP 协议与远程 java web 服务进行通信。对吧？

这里将在 HTTP 请求/响应正文中包含 SOAP 消息（XML 消息）。因此，在基于 REST 的 Web 服务中，再深入一层，HTTP 请求本身表现为消息。这里我们使用 WADL 而不是 WSDL。在这里，我们也可以基于 WADL 创建存根。所以除了一些技术差异之外，每件事看起来或多或少都是一样的消费者连接到生产者以及如何处理请求/响应。因此，据我了解，从开发人员的角度来看，基于 b/w 休息和基于肥皂的 Web 服务没有太大区别（开发人员的工作量几乎相同）。

我的理解正确吗？

是的，可能在幕后，可能 SOAP 比 REST Web 服务更复杂，因为在 SOAP 中，消息中有消息（SOAP 消息嵌入在 HTTP 请求中），但在基于 REST 的服务中，HTTP 请求本身作为消息工作。

【问题讨论】：

This answer 可以为您提供所需的指导。

标签： java web-services rest soap

【解决方案1】：

SOAP 和 REST 旨在解决一组相同的问题，即以最简单的方式促进异构应用程序之间的交互。现在是选择 REST 还是 SOAP 并不仅仅取决于开发工作量。您还应该考虑以下一些因素，

数据类型，无论是要在应用程序之间交换的简单对象（如名称值对）还是非常复杂的模式（或一些二进制数据）。
您的服务的消费者。例如。 REST 更适合你开发RIA。
安全要求。 SOAP 凭借标准驱动，提供了非常细粒度级别的安全方面调整。您可以在一定程度上对 SOAP xml 消息的各个元素进行编码。这些类型的事情在 REST 中是不可能的（至少目前是这样）。
如今，像 JSON 这样的符号在轻量级数据交换中非常流行，许多 REST 服务框架非常容易开箱即用地提供这一点。
从技术上讲，您不需要任何框架等来创建 REST Web 服务。我知道 WADL 等最近引入了标准化元素，但 REST 甚至在 WADL 出现之前就已经存在。 REST 并不是什么新鲜事，它是网络的工作方式。 REST 框架让这一切变得非常简单。

SOAP 是由标准驱动的，因此在使用它们时需要遵守更多的约束。因此，如果您的用例很简单（这是非常主观的），请选择 REST。

【讨论】：

Santosh 正如您所说的“REST 甚至在 WADL 出现之前就已经存在”。我的问题是没有 WADL（或其他一些描述），消费者如何知道生产者端公开的操作是什么？应该对生成的 Web 服务进行一些描述，以便消费者可以针对预期的 Web 服务。对吗？
我认为我发现的另一个主要区别是，在 REST 数据中（无论是它的 xml、json、字符串）作为名称值对传播，我们不必在基于肥皂的 Web 服务中生成存根/骨架，我们的数据在SOAP信封下作为XML消息传输，该信封位于http消息的正文下。此外，我们需要存根/骨架来实现互操作性。对吗？
@MSach WADL 引入了标准化元素，它更多地与提供工具帮助（生成存根等）有关，而不是与 REST 本身有关。从本质上讲，REST 只不过是 Web 工作的方式。您使用简单的 URL 指定资源。在 WADL 之前，您只需通过传递一些参数来调用 Web 服务并查看输出，或者服务提供者为每个服务示例提供详细的文档Google APIs。
@MSach，关于您提到的差异，是的，我们总是将数据作为 HTTP 表单方法（GET/POST 等）发送。但响应可以是任何东西，包括 JSON、简单的文本或复杂的 XML 树。 REST 不会限制你，这就是它的美丽和力量。这就是它们在简单用例中如此受欢迎的原因。关于互操作性，REST 也是可互操作的。您会看到 REST 使用的一切都是平台无关的。 HTTP、JSON、XML 等所有技术/平台中立标准。

【解决方案2】：

这是开发 Web 服务的两种不同方式……关于它们的区别（和优势）有很多讨论。

SOAP Web 服务远不止您所指的要点，实际上有一个完整的“堆栈”（WS-*）旨在标准化设计和实现此类 Web 服务的方法。这对某些系统来说很好，但对其他系统来说“太多”而且很重。在幕后 HTTP 是一种流行的“传输”消息的方式，但它不是唯一的，它们可以通过其他协议实现。在 SOAP 中，您严重依赖“WSDL”规范，该规范确实可用于“生成”服务器和客户端代码。在这些规范中，您非常关注“操作”，即在 Web 服务上要做的事情。

另一方面，在 REST 上，我们更多地考虑“资源”（由给定的 URI 描述），然后在它之上我们执行 HTTP 操作。尽管存在 WADL，但在 SOAP Web 服务中没有那么多规范的概念。实际上有一个很大的不同，人们并没有考虑太多（但实际上是 REST 原则核心的一部分），即在 REST 中你有所谓的“超链接”，其目的是允许客户端-服务器进行通信“状态”（下一步要去哪里），它在 SOAP Web 服务中不是那么“动态地”处理的。

底线，对于开发人员的观点：SOAP 确实有很多好的工具（例如：所有 Eclipse Web 服务工具），但是它往往有点麻烦并且有很多“代码”。 REST 开发通常更干净、更简单。我确实认为这两种解决方案都可以用作您正在处理的情况的功能，您不应该“选择一个”。例如，如果您有一个巨大的企业应用程序，有很多部分和相互依赖关系、事务处理等，那么带有 WSDL（合同）的 SOAP Web 服务可能是要走的路。另一方面，如果您向客户端公开一个 Web 服务（或 API），没有很多相互依赖关系，那么 REST 可能是最有趣的（您可以在过去 5 年左右的变化中看到这一点，所有主要的 Web APIS - google、twitter 等，现在都公开为 REST Web 服务）。

【讨论】：

正如您所说，“SOAP 往往有点麻烦，而且“代码”很多。REST 开发通常更干净、更简单”。我的观点似乎同样繁琐，并且涉及几乎相同数量的代码。你能详细解释一下你的陈述吗？提前致谢。
我的意思是：在 WSDL 中，您通常会生成大量代码（骨架和存根）来处理 Web 服务的通信。在 REST（例如：在 Java 中使用 Jersey）中，您拥有服务器代码，例如：API 资源，由类上的 Java 方法处理，并且您向该方法添加一个简单的注释以在您的 API 中公开它，这很漂亮很多（请参阅泽西岛的这个 hello world 示例：mkyong.com/webservices/jax-rs/jersey-hello-world-example）。这就是为什么我提到它往往更清洁。但同样，在某些情况下 SOAP Web 服务可能更适合。

【解决方案3】：

没有大的区别（尤其是从开发人员的角度来看）。

唯一真正的区别是 SOAP 是根据 WS-* 建议进行标准化的。此外，在 SOAP 中，还可以根据标准创建事务并保护消息本身。因此，对于互操作性，SOAP 具有基于此的优势。

【讨论】：