1311

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

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

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

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

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

4

13 回答 13

1818

不幸的是，围绕 REST 存在很多错误信息和误解。不仅您的问题和@cmd 的答案反映了这些问题，而且大多数问题和答案都与 Stack Overflow 上的主题相关。

SOAP 和 REST 不能直接比较，因为前者是一种协议（或至少试图如此），而后者是一种架构风格。这可能是造成混淆的原因之一，因为人们倾向于将 REST 称为任何不是 SOAP 的 HTTP API。

稍微推动一下并试图建立一个比较，SOAP 和 REST 之间的主要区别在于客户端和服务器实现之间的耦合程度。SOAP 客户端的工作方式类似于自定义桌面应用程序，与服务器紧密耦合。客户端和服务器之间有一个严格的合同，如果任何一方改变任何东西，一切都会被打破。您需要在任何更改后不断更新，但更容易确定是否遵守了合同。

REST 客户端更像是浏览器。它是一个知道如何使用协议和标准化方法的通用客户端，应用程序必须适应其中。您不会通过创建额外的方法来违反协议标准，您可以利用标准方法并在您的媒体类型上使用它们创建操作。如果做得好，耦合就会减少，并且可以更优雅地处理更改。除了入口点和媒体类型外，客户端应该在对 API 零知识的情况下进入 REST 服务。在 SOAP 中，客户端需要事先了解它将使用的所有内容，否则它甚至不会开始交互。此外，可以通过服务器本身提供的按需代码来扩展 REST 客户端，

我认为这些是理解 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 应该完成的方式设计 Web，而不是有一个带有问题和答案链接的主页，我们会有一个静态文档解释，为了查看问题，你必须获取 URI stackoverflow.com/questions/<id>，用 Question.id 替换 id 并将其粘贴到浏览器上。这是胡说八道，但这就是许多人认为的 REST。

最后一点怎么强调都不过分。如果您的客户正在从文档中的模板构建 URI，而不是在资源表示中获取链接，那不是 REST。REST 的作者 Roy Fielding 在这篇博文中明确表示：REST API 必须是超文本驱动的。

考虑到上述内容，您将意识到虽然 REST 可能不限于 XML，但要正确使用任何其他格式，您必须为链接设计和标准化某种格式。超链接在 XML 中是标准的，但在 JSON 中不是。JSON 有一些标准草案，例如HAL。

最后，REST 并不适合所有人，这就是大多数人如何使用他们错误地称为 REST 并且从未冒险超越的 HTTP API 很好地解决他们的问题的一个证明。REST 有时很难做到，尤其是在刚开始的时候，但随着时间的推移，它会随着服务器端更容易的演变以及客户端对变化的弹性而付出代价。如果您需要快速轻松地完成某些事情，请不要为正确使用 REST 而烦恼。这可能不是你要找的。如果您需要一些必须保持在线数年甚至数十年的东西，那么 REST 适合您。

于 2013-11-10T00:45:24.517 回答
303

RESTvsSOAP不是正确的问题。

REST，不像SOAP不是协议。

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

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

@Abdulaziz 的问题确实说明了一个事实，REST并且HTTP经常被串联使用。这主要是由于 HTTP 的简单性及其与 RESTful 原则的非常自然的映射。

基本 REST 原则

客户端-服务器通信

客户端-服务器架构具有非常明显的关注点分离。所有以 RESTful 风格构建的应用程序原则上也必须是客户端-服务器。

无状态

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

可缓存

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

统一接口

所有组件都必须通过一个统一的接口进行交互。因为所有的组件交互都是通过这个接口进行的，所以与不同服务的交互非常简单。界面是一样的！这也意味着可以单独进行实施更改。此类更改不会影响基本组件交互，因为统一接口始终保持不变。一个缺点是你被界面卡住了。如果可以通过更改接口为特定服务提供优化，那么您就不走运了，因为 REST 禁止这样做。然而，好的一面是，REST 针对 Web 进行了优化，因此 REST over HTTP 非常受欢迎！

上述概念代表了 REST 的定义特征，并将 REST 架构与其他架构（如 Web 服务）区分开来。请注意，REST 服务是一种 Web 服务，但 Web 服务不一定是 REST 服务。

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

编辑：根据评论更新内容

于 2013-11-09T23:19:50.730 回答
249
于 2015-06-14T19:48:27.733 回答
139

REST（RE表示状态传输）对象的 RE表示状态被传输是REST即我们不发送对象，我们发送对象的状态。REST 是一种架构风格。它没有像 SOAP 那样定义那么多标准。REST 用于通过 Internet 公开公共 API（即 Facebook API、Google Maps API）以处理数据的 CRUD 操作。REST 专注于通过单一一致的接口访问命名资源。

SOAP（简单对象访问协议）SOAP带来了 自己的协议，并专注于将应用程序逻辑（而非数据）片段公开为服务。SOAP 公开操作。SOAP 专注于访问命名操作，每个操作都实现一些业务逻辑。尽管 SOAP 通常被称为Web 服务，但这是用词不当。SOAP 与 Web 几乎没有任何关系。REST 提供基于 URI 和 HTTP 的 真正Web 服务。

为什么是 REST？

  • 由于 REST 使用标准 HTTP，它几乎以任何方式都简单得多。
  • REST 更容易实现，需要更少的带宽和资源。
  • REST 允许许多不同的数据格式，而 SOAP 只允许 XML。
  • 由于对 JSON 的支持，REST 可以更好地支持浏览器客户端。
  • REST 具有更好的性能和可扩展性。REST 读取可以缓存，基于 SOAP 的读取不能缓存。
  • 如果安全不是主要问题并且我们的资源有限。或者我们想创建一个其他开发人员可以轻松公开使用的 API，那么我们应该使用 REST。
  • 如果我们需要无状态 CRUD 操作，请使用 REST。
  • REST 常用于社交媒体、网络聊天、移动服务和 Google 地图等公共 API。
  • RESTful 服务为同一资源返回各种 MediaType，具体取决于请求标头参数“Accept”作为POSTapplication/xml或GET 或GET。application/json/user/1234.json/user/1234.xml
  • REST 服务旨在由客户端应用程序调用，而不是由最终用户直接调用。
  • ST in REST来自于State Transfer 。您转移状态而不是让服务器存储它，这使得 REST 服务具有可扩展性。

为什么是肥皂？

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

在此处输入图像描述

来源1 来源
2

于 2015-12-08T23:38:04.510 回答
25

恕我直言，您无法比较 SOAP 和 REST，因为它们是两种不同的东西。

SOAP是一种协议，而REST是一种软件架构模式。互联网上有很多关于SOAP 与 REST的误解。

SOAP定义了基于 XML 的消息格式，支持 Web 服务的应用程序使用该格式在 Internet 上相互通信。为了做到这一点，应用程序需要事先了解消息契约、数据类型等。

REST表示来自 URL 的服务器的状态（作为资源）。它是无状态的，客户端不应该有与服务器交互的先验知识，超出对超媒体的理解。

于 2016-01-17T00:17:05.477 回答
19

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

因为，虽然web 服务，是在松散意义上使用的，但是当使用 HTTP 协议而不是网页来传输数据时，正式它是该思想的一种非常具体的形式。根据定义，REST 不是“Web 服务”。

然而在实践中，每个人都忽略了这一点，所以我们也忽略它

已经有技术答案，所以我会尝试提供一些直觉。

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

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

对于第一个问题，官方的定义是WSDL。这是一个 XML 文件，它以详细和严格的格式描述了参数是什么、它们的类型、名称、默认值、要调用的函数的名称等。这里的示例 WSDL表明该文件是人为的- 可读（但不容易）。

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

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

  • myapp/read-customer并在消息正文中传递要读取的客户 ID。
  • myapp/update-customer在正文中，传递客户的 id 以及新数据
  • myapp/delete-customer和正文中的id

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

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

有关服务必须满足才能被视为真正 RESTful 的要求的更多详细信息，请参阅Richardson 成熟度模型。文章给出了示例，更重要的是，解释了为什么（所谓的）SOAP 服务是 0 级 REST 服务（虽然，0 级意味着对这种模型的低遵从性，但它并不令人反感，它仍然有用在许多情况下）。

于 2018-08-15T18:19:17.697 回答
14

在许多答案中已经涵盖的许多其他内容中，我要强调的是 SOAP 可以定义一个契约，即 WSDL，它定义了支持的操作、复杂类型等。SOAP 面向操作，但 REST 面向资源。就我个人而言，我会选择 SOAP 作为内部企业应用程序之间的复杂接口，而选择 REST 作为与外部世界的公共、更简单、无状态的接口。

在此处输入图像描述

于 2018-05-23T15:41:13.397 回答
10

补充：

++ 使用 REST 时经常犯的一个错误是将其视为“带有 URL 的 Web 服务”——将 REST 视为另一种远程过程调用 (RPC) 机制，如 SOAP，但通过纯 HTTP URL 调用，没有 SOAP 的强大功能XML 命名空间。

++ 相反，REST 与 RPC 关系不大。RPC 是面向服务的，专注于动作和动词，而 REST 是面向资源的，强调构成应用程序的事物和名词。

于 2016-09-20T08:02:14.140 回答
9

很多这些答案完全忘记提及对 REST 来说完全是基础的超媒体控件 (HATEOAS)。其他一些人谈到了它，但并没有真正解释得那么好。

本文应该解释这些概念之间的区别，而不是深入讨论特定的 SOAP 特性。

于 2018-01-05T00:17:44.133 回答
0

什么是 REST

REST 代表具象状态转移，它实际上是一种用于创建 Web API 的架构风格，它将一切（数据或功能）视为资源。它期望；通过URI暴露资源并以多种格式响应并以无状态方式表示资源状态的传输。这里我说两件事：

  1. 无状态方式：由 HTTP 提供。
  2. 状态的代表性转移：例如，如果我们要添加员工。. 进入我们的系统，它处于HTTP的POST状态，之后它将处于HTTP的GET状态，同样的PUT和DELETE。

REST 可以使用 SOAP Web 服务，因为它是一个概念，可以使用任何协议，例如 HTTP，SOAP.SOAP 使用服务接口来公开业务逻辑。REST 使用 URI 来公开业务逻辑。

没有 HATEOAS 的 REST 不是 REST。这意味着客户端只知道入口点 URI，并且资源应该返回客户端应该遵循的链接。那些为您可以在 REST API 中执行的所有操作提供 URI 模式的精美文档生成器完全没有抓住重点。他们不仅记录了应该遵循标准的东西，而且当你这样做时，你将客户端耦合到 API 演变中的一个特定时刻，并且必须记录和应用对 API 的任何更改，否则它会破裂。

HATEOAS 是 Hypermedia As The Engine Of Application State 的缩写，是 REST 应用程序架构的一个约束，将其与大多数其他网络应用程序架构区别开来。其原理是客户端完全通过应用服务器动态提供的超媒体与网络应用进行交互。除了对超媒体的一般理解之外，REST 客户端不需要有关如何与任何特定应用程序或服务器交互的先验知识。相比之下，在一些面向服务的体系结构 (SOA) 中，客户端和服务器通过文档或接口描述语言 (IDL) 共享的固定接口进行交互。

参考 1 参考 2

于 2020-09-16T19:30:20.013 回答
0

要回答这个问题，了解分布式应用程序架构从简单的分层架构到基于对象和服务、再到基于资源的演变是很有用的，现在我们甚至有了基于事件的架构。大多数大型系统都使用样式组合。

第一个分布式应用程序具有分层架构。我假设这里的每个人都知道什么是层。这些结构组织整齐，可以是堆栈或循环结构。努力保持单向数据流。

基于对象的架构是从分层架构演变而来的，并遵循更松散的模型。在这里，每个组件都是一个对象（通常称为分布式对象）。对象使用类似于远程过程调用的机制相互交互——当客户端绑定到分布式对象时，它会将对象接口的实现加载到其地址空间中。RPC 存根可以编组请求并接收响应。同样，服务器上的对象接口是一个 RPC 样式的存根。这些基于对象的系统的结构没有那么整齐，它看起来更像一个对象图。

分布式对象的接口隐藏了它的实现。与分层组件一样，如果明确定义了接口，则可以更改内部实现——甚至完全替换。基于对象的体系结构为封装服务提供了基础。服务由一个独立的实体提供，尽管它在内部可以使用其他服务。基于对象的体系结构逐渐演变为面向服务的体系结构 (SOA)。</p>

使用 SOA，分布式应用程序由服务组成。这些服务可以跨管理域提供——它们可以通过网络获得（即由云提供商提供的存储服务）。

随着 Web 服务变得流行，越来越多的应用程序开始使用它们，服务组合（组合服务以形成新的服务）变得更加重要。SOA 的问题之一是集成不同的服务可能变得极其复杂。


虽然 SOAP 是一种协议，但它的使用意味着面向服务的体系结构。SOAP 试图为服务提供一个标准，使它们可以组合并易于集成。

基于资源的架构是解决 SOA 集成问题的不同方法。这个想法是将分布式系统视为由组件单独管理的巨大资源集合。这导致了 RESTful 架构的发展。RESTful 服务的特征之一是无状态执行。这与服务器维护状态的 SOA 不同。

那么……与基于资源的架构（如 REST）相比，面向服务的架构（包括使用 SOAP 的架构）提供的特定于服务的接口如何？



虽然 REST 很简单，但它并没有为复杂的通信方案提供简单的接口。例如，如果您需要使用事务 REST 不合适，最好将复杂的状态封装在服务器上，而不是让客户端管理事务。但是在许多场景中，RESTful 架构中资源的正交使用极大地简化了服务的集成，否则这意味着服务接口的爆炸式增长。另一个权衡是基于资源的架构增加了客户端的复杂性并增加了网络流量，而基于服务的架构增加了服务器的复杂性并对其内存和 CPU 资源征税。

也有人提到了常见的 HTTP 服务或其他不满足 RESTful 架构或 SOAP 要求的服务。这些也可以分为基于服务的或基于资源的。这些具有更易于实现的优点。如果您知道您的服务永远不需要跨管理域集成，您只会使用这种方法，因为这不会尝试解决出现的集成问题。

这些基于 HTTP 的服务，尤其是伪 RESTful 服务仍然是最常见的类型。实现 SOAP 很复杂，只有在您真正需要时才应该使用它 - 即您需要一个可以轻松跨域集成的服务，并且您希望它有一个服务接口。仍然存在需要这样做的情况。真正的 RESTful 服务也很难实现，尽管不如 SOAP 难。

于 2021-10-17T04:17:38.260 回答
0

REST API

RESTful API 是最著名的 API 类型。REST 代表代表性状态转移。

REST API 是遵循标准化原则、属性和约束的 API。

您可以使用 HTTP 动词访问 REST API 中的资源。

REST API 在简单的请求/响应系统上运行。您可以使用以下 HTTP 方法发送请求：

  • 得到
  • 邮政
  • 放
  • 修补
  • 删除
  • 痕迹
  • 选项
  • 连接
  • 头

以下是最常见的 HTTP 动词

  • GET（读取现有数据）
  • POST（创建新的响应或数据）
  • PATCH（更新数据）
  • DELETE（删除数据）

客户端可以使用 HTTP 动词后跟端点发出请求。

端点（或路由）是您请求的 URL。路径决定了您请求的资源。

当您向端点发送请求时，它会使用相关数据进行响应，通常格式为 JSON、XML、纯文本、图像、HTML 等。

REST API 也可以设计为具有许多返回不同类型数据的不同端点。使用 REST API 访问多个端点需要各种 API 调用。

实际的 RESTful API 遵循以下五个约束：

  1. 客户端-服务器架构
    客户端从服务器请求数据，没有第三方解释。

  2. 无状态 无
    状态意味着每个 HTTP 请求都是在完全隔离的情况下发生的。每个请求都包含服务请求所需的信息。服务器从不依赖来自先前请求的信息。没有状态。

  3. 可缓存
    性响应可以显式或隐式定义为可缓存或不可缓存，以提高可伸缩性和性能。例如，开启 GET 请求的缓存可以提高资源数据请求的响应时间。

  4. 分层
    API 架构的不同层应该协同工作，创建一个易于更新或调整的可扩展系统。

  5. 客户端和服务器之间的统一接口
    通信必须使用独立于两者的标准化语言来完成。这提高了可扩展性和灵活性。

REST API 非常适合需要

  • 灵活的
  • 可扩展
  • 快速地

SOAP API

SOAP 是一种必要的协议，有助于引入 API 的广泛使用。

SOAP 是简单对象访问协议的首字母缩写。

SOAP 是一种标准化协议，它依赖于 XML 来发出请求和接收响应。

尽管 SOAP 基于 XML，但 SOAP 协议仍在广泛使用。

SOAP API 将数据作为服务提供，通常在执行涉及多个 API 调用的事务或以安全为主要考虑因素的应用程序时使用。

SOAP 最初于 1998 年为 Microsoft 开发，旨在提供一种标准机制，用于在 Internet 上集成服务，而不管操作系统、对象模型或编程语言如何。

SOAP 中的“S”代表 Simple，这是有充分理由的 - SOAP 可以以较低的复杂性使用，因为它在应用程序层中对事务、安全性和其他功能的编码需要较少。

SOAP 具有三个主要特征：

  1. SOAP API 的可扩展性
    SOAP 允许扩展引入更强大的功能，例如 Windows Server 安全性、寻址等。

  2. SOAP API 的中立性 SOAP
    能够在广泛的协议上运行，例如 UDP、JMS、SMTP、TCP 和 HTTP。可以运行。

  3. SOAP API 的独立性
    SOAP API 响应完全基于 XML。因此 SOAP API 是独立于平台和语言的。

开发人员继续争论使用 SOAP 和 REST 的利弊。最适合您的项目的将是符合您需求的项目。

  • 尽管 REST 在很大程度上主导了 Web 应用程序，但 SOAP API 仍然是优先考虑安全性的企业实体和政府组织的首选。

  • SOAP 比 REST 更安全，因为它使用 WS-Security 和安全套接字层进行传输

  • SOAP 还具有更出色的事务可靠性，这也是 SOAP 历来受到银行业和其他大型实体青睐的另一个原因。

于 2021-11-11T10:53:24.733 回答
0

尽管 SOAP 和 REST 在 HTTP 协议上具有相似之处，但 SOAP 是一组比 REST 更严格的消息传递模式。SOAP 中的规则是相关的，因为没有它们我们就无法实现任何程度的标准化。REST 作为一种架构风格不需要处理，并且本质上更加通用。本着信息交换的精神，SOAP 和 REST 都依赖于每个人都决定遵守的完善的法律。SOAP 与 REST 的选择取决于您所使用的编程语言、您所使用的环境和规范。

于 2020-11-17T17:52:24.640 回答