SOAP 与 REST（差异）

我已经阅读了有关 SOAP 和 REST 作为 Web 服务通信协议之间的区别的文章，但是我认为 REST 相对于 SOAP 的最大优势在于：

  1. REST 更动态，无需创建和更新 UDDI（通用描述，发现和集成）。

  2. REST 不仅限于 XML 格式。 RESTful Web 服务可以发送纯文本 / JSON / XML。

但是 SOAP 更加标准化（例如：安全性）。

那么，我在这些方面是否正确？

答案

不幸的是，关于 REST 有很多误解和误解。 @cmd 不仅反映了您的问题和答案 ，而且与 Stack Overflow 上的主题相关的大多数问题和答案。

SOAP 和 REST 无法直接进行比较，因为第一个是协议（或至少是协议），第二个是体系结构样式。这可能是引起混乱的根源之一，因为人们倾向于将 REST 称为不是 SOAP 的任何 HTTP API。

稍作努力并尝试建立比较，SOAP 和 REST 之间的主要区别在于客户端和服务器实现之间的耦合程度。 SOAP 客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合。客户端和服务器之间存在严格的合同，如果任何一方更改任何内容，一切都会中断。在进行任何更改后，您需要不断更新，但更容易确定是否遵守合同。

REST 客户端更像是浏览器。这是一个通用客户端，知道如何使用协议和标准化方法，并且应用程序必须适合其中。您不会通过创建其他方法来违反协议标准，而是可以使用标准方法并在您的媒体类型上使用它们来创建操作。如果做得正确，耦合度就会降低，并且可以更优雅地处理更改。除了入口点和媒体类型之外，客户端应该以对 API 零知识的方式进入 REST 服务。在 SOAP 中，客户端需要有关将要使用的所有内容的先前知识，或者甚至不会开始交互。另外，REST 客户端可以通过服务器本身提供的按需代码进行扩展，经典示例是 JavaScript 代码，该代码用于驱动与客户端另一服务的交互。

我认为这些是了解 REST 的意义以及与 SOAP 有何不同的关键点：

  • REST 与协议无关。它没有耦合到 HTTP。就像您可以在网站上跟随 ftp 链接一样，REST 应用程序可以使用具有标准化 URI 方案的任何协议。

  • REST 不是 CRUD 到 HTTP 方法的映射。阅读此答案以获取有关此内容的详细说明。

  • REST 与您使用的部件一样标准化。 HTTP 中的安全性和身份验证是标准化的，因此这就是在 HTTP 上进行 REST 时使用的方式。

  • 没有超媒体和HATEOAS 的 REST 就不是 REST。这意味着客户端仅知道入口点 URI，并且资源应返回客户端应遵循的链接。这些花哨的文档生成器为您在 REST API 中可以执行的所有操作提供 URI 模式，这完全忽略了这一点。他们不仅在记录本应遵循该标准的内容，而且在这样做时，您将客户端与 API 演进中的特定时刻联系在一起，并且必须记录和应用 API 上的任何更改，否则会破裂。

  • REST 是 Web 本身的体系结构样式。当您输入 Stack Overflow 时，您知道什么是用户，问题和答案，媒体类型，并且网站为您提供了指向它们的链接。 REST API 必须执行相同的操作。如果我们以人们认为 REST 的方式设计网络，而不是使用带有问答链接的主页，则将有一个静态文档说明要查看问题，您必须采取 URI stackoverflow.com/questions/<id> ，将 ID 替换为 Question.id 并将其粘贴到浏览器中。那是胡扯，但这就是许多人认为 REST 的含义。

最后一点不能足够强调。如果您的客户是从文档中的模板构建 URI，而未在资源表示中获得链接，则不是 REST。 REST 的作者 Roy Fielding 在此博客文章中明确指出： REST API 必须是超文本驱动的 。

考虑到以上几点，您将认识到，尽管 REST 可能不限于 XML，但要正确地使用其他任何格式，则必须为链接设计和标准化某种格式。超链接是 XML 的标准配置，但不是 JSON 的标准配置。有 JSON 的标准草案，例如HAL 。

最后，REST 并不适合所有人，这证明了大多数人如何使用错误地称为 REST 的 HTTP API 很好地解决他们的问题，并且永不冒险。 REST 有时很难做到，尤其是在开始时，但是随着时间的流逝，它会在服务器端更轻松地演进以及客户对变更的适应力中付出代价。如果您需要快速，轻松地完成某件事，请不要担心正确使用 REST。可能不是您要找的东西。如果您需要某些东西必须保持在线状态长达数年甚至数十年，那么 REST 适合您。

REST vs SOAP 不是正确的问题。

REST与SOAP不同，它不是协议。

REST是一种架构风格和基于网络的软件架构设计 。

REST概念称为资源。资源的表示形式必须是无状态的。它通过某种媒体类型表示。媒体类型的一些示例包括XML ， JSON和RDF 。资源由组件操纵。组件通过标准的统一接口请求和操纵资源。对于 HTTP，此接口由标准 HTTP 操作组成，例如GET ， PUT ， POST ， DELETE 。

@Abdulaziz 的问题确实说明了REST和HTTP经常串联使用的事实。这主要是由于 HTTP 的简单性及其对 RESTful 原理的非常自然的映射。

REST 基本原理

客户端 - 服务器通信

客户端 - 服务器体系结构的关注点非常不同。原则上，以 RESTful 样式构建的所有应用程序也必须是客户端服务器。

无状态

每个对服务器的客户端请求都要求完全表示其状态。服务器必须能够完全理解客户端请求，而无需使用任何服务器上下文或服务器会话状态。因此，所有状态都必须保留在客户端上。

可缓存

可以使用缓存约束，从而使响应数据可以标记为可缓存或不可缓存。任何标记为可缓存的数据都可以重用作为对相同后续请求的响应。

统一接口

所有组件都必须通过一个统一的界面进行交互。因为所有组件交互都是通过此接口发生的，所以与不同服务的交互非常简单。界面是一样的！这也意味着可以单独进行实现更改。这样的更改不会影响基本组件的交互，因为统一接口始终不变。一个缺点是您被接口卡住了。如果可以通过更改接口来为特定服务提供优化，则您很不走运，因为 REST 禁止这样做。从好的方面来说，REST 是针对 Web 优化的，因此 REST 在 HTTP 上的普及程度令人难以置信！

以上概念代表了 REST 的定义特征，并将 REST 体系结构与其他体系结构（如 Web 服务）区分开来。值得注意的是，REST 服务是 Web 服务，但是 Web 服务不一定是 REST 服务。

有关REST和上述项目符号的更多详细信息，请参见有关REST 设计原则的博客文章 。

编辑： 根据评论更新内容

SOAP（ 简单对象访问协议 ）和 REST（ 表示状态传输 ）两者的方式都很漂亮。所以我没有比较它们。相反，当我更喜欢使用 REST 和 SOAP 时，我试图描绘出这张图。

什么是有效载荷？

当数据通过 Internet 发送时，每个发送的单元都包括标头信息和实际发送的数据。标头标识数据包的源和目的地， 而实际数据称为有效负载 。通常，有效负载是代表应用程序承载的数据和目标系统接收的数据。

例如，现在我必须发送电报 ，我们都知道电报的费用将取决于某些单词。

因此，请在下面提到的这两个消息中告诉我，哪个消息发送起来更便宜？ 

<name>Arin</name>

要么

"name": "Arin"

我知道您的答案将是第二个，尽管两者都表示相同的消息。第二个在成本方面更便宜。

因此，我想说的是， 以 JSON 格式通过网络发送数据要比以 XML 格式发送有关有效负载的数据便宜 。

这是 REST 相对于 SOAP 的第一个优点或优点 。 SOAP 仅支持 XML，但是 REST 支持不同的格式，例如文本，JSON，XML 等。而且我们已经知道，如果使用 Json，那么在有效负载方面肯定会处于更好的位置。

现在，SOAP 仅支持 XML， 但也有其优势。

真！怎么样？

SOAP 通过三种方式依赖 XML 信封 - 定义消息中包含的内容以及如何对其进行处理。

一组用于数据类型的编码规则，最后是过程调用和响应的布局。

该信封通过传输（HTTP / HTTPS）发送，并执行 RPC（远程过程调用），并且信封以 XML 格式的文档中的信息返回。

重要的一点是， SOAP 的优点之一是使用“通用” 传输，而REST 使用 HTTP / HTTPS 。 SOAP 几乎可以使用任何传输方式发送请求，而 REST 不能。因此，这里我们有了使用 SOAP 的优势。

正如我在上一段“REST 使用 HTTP / HTTPS” 中已经提到的那样，请对这些词进行更深入的介绍。

当我们谈论基于 HTTP 的 REST 时，HTTP 所应用的所有安全措施都是继承的，这就是所谓的传输级安全性 ，它仅在消息位于线路内部时保护消息的安全 ，但是一旦在另一端传递消息，您就不会知道在到达将要处理数据的实际点之前，它必须经历多少个阶段。当然，所有这些阶段都可以使用与 HTTP 不同的东西。 因此，休息并不完全安全，对吗？

但是 SOAP 像 REST 一样支持 SSL ，它还支持 WS-Security ，它增加了一些企业安全性功能。 WS-Security 提供了从创建消息到使用消息的保护。因此，对于传输级安全性，我们发现可以使用 WS-Security 避免的任何漏洞。

除此之外，由于REST 受 HTTP 协议的限制，因此它的事务支持既不符合 ACID，也不能提供跨分布式跨国资源的两阶段提交。

但是 SOAP 全面支持短期交易的基于 ACID 的交易管理和长期交易的基于补偿的交易管理。它还支持跨分布式资源的两阶段提交 。

我没有得出任何结论，但是我将更喜欢基于 SOAP 的 Web 服务，而安全，事务等是主要关注点。

在这里的 “Java EE 6 教程” 中， 当满足以下条件时 ，他们说RESTful 设计可能是合适的 。看一看。

希望您喜欢阅读我的回答。

REST（RE表象的小号泰特贸易交接）
RE表象S上的对象为T ransferred 是 REST，即我们不会发送对象，我们发送对象的状态泰特。 REST 是一种建筑风格。它没有定义很多标准，例如 SOAP。 REST 用于通过 Internet 公开公共 API（即 Facebook API，Google Maps API）以处理数据的 CRUD 操作。 REST 专注于通过单个一致的接口访问命名资源。

SOAP（šimpleöbject 甲 CCESS P rotocol）
SOAP 带来了自己的协议，并着重于将应用程序逻辑部分（而非数据）公开为服务。 SOAP 公开操作。 SOAP 专注于访问命名操作，每个操作实现一些业务逻辑。尽管 SOAP 通常被称为Web 服务，但这是错误的称呼。 SOAP 与 Web 几乎没有关系。 REST 提供基于 URI 和 HTTP 的真正的Web 服务 。

为什么要 REST？

  • 由于 REST 使用标准的 HTTP，因此它几乎在所有方面都更加简单。
  • REST 更易于实现，需要更少的带宽和资源。
  • REST 允许许多不同的数据格式，而 SOAP 仅允许 XML。
  • REST 由于支持 JSON，因此可以更好地支持浏览器客户端。
  • REST 具有更好的性能和可伸缩性。可以缓存 REST 读取，不能缓存基于 SOAP 的读取。
  • 如果安全不是主要问题，并且我们的资源有限。或者，我们想创建一个可供其他开发者公开使用的 API，那么我们应该使用 REST。
  • 如果我们需要无状态 CRUD 操作，请使用 REST。
  • REST 通常用于社交媒体，网络聊天，移动服务和 Google Maps 等公共 API。
  • RESTful 服务回报各种 MediaTypes 对于相同的资源，根据请求报头参数 “接受” 作为application/xml或application/json为 POST 和/user/1234.json或 GET /user/1234.xml为 GET。
  • REST 服务应由客户端应用程序而不是最终用户直接调用。
  • ST中其余则选自S大老贸易交接。您转移状态而不是由服务器存储状态，这使 REST 服务具有可伸缩性。

为什么要使用 SOAP？

  • SOAP 并不是很容易实现，并且需要更多的带宽和资源。
  • 与 REST 相比，处理 SOAP 消息请求的速度较慢，并且不使用 Web 缓存机制。
  • WS-Security：尽管 SOAP 支持 SSL（就像 REST 一样），但它也支持 WS-Security，它增加了一些企业安全性功能。
  • WS-AtomicTransaction：在服务上需要 ACID 事务，您将需要 SOAP。
  • WS-ReliableMessaging：如果您的应用程序需要异步处理以及有保证的可靠性和安全性。 Rest 没有标准的消息传递系统，希望客户端通过重试来处理通信失败。
  • 如果安全是主要问题，并且资源没有限制，那么我们应该使用 SOAP Web 服务。就像我们要创建用于支付网关，金融和电信相关工作的 Web 服务一样，我们应该使用 SOAP，因为这里需要很高的安全性。

在此处输入图片说明

来源 1
来源 2

休息和肥皂之间的区别

肥皂

  1. SOAP 是一种协议。
  2. SOAP 代表简单对象访问协议。
  3. SOAP 无法使用 REST，因为它是一个协议。
  4. SOAP 使用服务接口来公开业务逻辑。
  5. SOAP 定义了必须严格遵循的标准。
  6. SOAP 比 REST 需要更多的带宽和资源。
  7. SOAP 定义了自己的安全性。
  8. SOAP 仅允许 XML 数据格式。
  9. SOAP 不如 REST 优先。

休息

  1. REST 是一种建筑风格。
  2. REST 代表代表性状态转移。
  3. REST 可以使用 SOAP Web 服务，因为它是一个概念，可以使用 HTTP，SOAP 等任何协议。
  4. REST 使用 URI 公开业务逻辑。
  5. REST 没有定义太多的标准，例如 SOAP。
  6. REST 比 SOAP 需要更少的带宽和资源。
  7. RESTful Web 服务从基础传输继承安全措施。
  8. REST 允许使用不同的数据格式，例如纯文本，HTML，XML，JSON 等。
  9. REST 比 SOAP 更可取。

有关更多详细信息，请参见此处

恕我直言，您无法比较 SOAP 和 REST，因为两者是两个不同的地方。

SOAP是一种协议， REST是一种软件体系结构模式。互联网上对于SOAP 与 REST有很多误解。

SOAP定义了基于 XML 的消息格式，支持 Web 服务的应用程序使用该消息格式通过 Internet 相互通信。为了做到这一点，应用程序需要消息合约，数据类型等方面的先验知识。

REST通过 URL 表示服务器的状态（作为资源），它是无状态的，并且客户端不应该具有对超媒体的了解，与服务器进行交互的先验知识。

首先：正式地，正确的问题是web services + WSDL + SOAP与REST 。

因为尽管松散地使用了Web 服务 ，但是当使用 HTTP 协议而不是网页传输数据时 ， 正式地说，这是该思想的一种非常具体的形式。根据定义，REST 不是 “Web 服务”。

但是实际上，每个人都忽略了这一点，所以我们也忽略它

已经有了技术上的答案，因此我将尝试提供一些直觉。

假设您要在远程计算机上调用以其他编程语言实现的函数（通常称为远程过程调用 / RPC ）。假定可以在编写者提供的特定 URL 上找到该函数。您必须（以某种方式）向其发送消息，并获得一些响应。因此，有两个主要问题需要考虑。

  • 您应该发送的消息格式是什么
  • 消息应该如何来回传递

对于第一个问题，正式定义是WSDL 。这是一个 XML 文件，以详细且严格的格式描述参数是什么，参数的类型，名称，默认值，要调用的函数的名称等。此处的WSDL 示例显示该文件是人的可读（但不容易）。

对于第二个问题，有各种各样的答案。但是，实践中唯一使用的是SOAP 。它的主要思想是：将先前的 XML（实际消息）包装到另一个 XML（包含编码信息和其他有用的东西）中，然后通过 HTTP 发送。 HTTP 的 POST 方法用于发送消息，因为始终有一个 body 。

整个方法的主要思想是将URL 映射到一个函数 ，即一个 action 。因此，如果您在某个服务器上有一个客户列表，并且想要查看 / 更新 / 删除一个客户，则必须有 3 个 URL：

  • myapp/read-customer并在邮件正文中传递要读取的客户的 ID。
  • myapp/update-customer并在正文中传递客户的 ID 以及新数据
  • myapp/delete-customer和主体中的 ID

REST 方法对事物的看法不同。 URL 不应代表动作，而应代表事物 （在 REST 术语中称为资源 ）。由于 HTTP 协议（我们已经在使用）支持动词，因此请使用这些动词来指定对事物执行什么动作 。

因此，使用 REST 方法，可以在 URL myapp/customers/12上找到 12 号myapp/customers/12 。要查看客户数据，请使用 GET 请求命中 URL。要删除它，请使用带有 DELETE 动词的相同 URL。要再次更新它，请使用带有 POST 动词的相同 URL，并在请求正文中添加新内容。

有关必须满足的服务才能被视为真正的 RESTful 的更多详细信息，请参阅Richardson 成熟度模型 。本文提供了示例，并且更重要的是，解释了为什么（所谓的）SOAP 服务是 0 级 REST 服务（尽管 0 级意味着对该模型的合规性较低，这不是令人反感的，并且仍然有用）在许多情况下）。

在许多答案中已经涵盖的许多其他问题中，我要强调的是，SOAP 能够定义合同，WSDL，WSDL 定义支持的操作，复杂类型等。SOAP 面向操作，而 REST 面向资源。就个人而言，我会选择 SOAP 来实现内部企业应用程序之间的复杂接口，而选择 REST 来实现与外界的公共，简单，无状态的接口。

在此处输入图片说明

除了：

++ 接近 REST 时常犯的一个错误是将其视为 “带有 URL 的 Web 服务”- 将 REST 视为另一种远程过程调用（RPC）机制，例如 SOAP，但通过普通 HTTP URL 调用而没有 SOAP 的麻烦 XML 名称空间。

++ 相反，REST 与 RPC 无关。 RPC 是面向服务的，并且侧重于动作和动词，而 REST 是面向资源的，强调了组成应用程序的事物和名词。

这些答案中有很多都完全忘记了提及 REST 根本所需的超媒体控件（HATEOAS）。其他一些人对此有感触，但并没有很好地解释它。

本文应该解释这些概念之间的区别，而不必深入了解特定的 SOAP 功能。