为什么基于 SOAP 的 Web 服务不是 RESTful？答案

【问题标题】：Why isn't SOAP-based web service RESTful?为什么基于 SOAP 的 Web 服务不是 RESTful？
【发布时间】：2023-03-12 18:14:01
【问题描述】：

我了解 RESTful 是一种架构风格，但究竟是什么让基于 SOAP 的 Web 服务不属于 RESTful？

我不清楚下面哪些点（来自Wikipedia）不符合 SOAP。

客户端-服务器
无状态
可缓存
分层系统
按需代码（可选）
统一界面
- 资源识别
- 通过这些表示来操纵资源
- 自我描述的消息
- 超媒体作为应用程序状态的引擎

编辑：我刚刚遇到this，它总结得很好。

REST 不是 RPC，RPC 说，“定义一些做某事的方法” 而 REST 说，“定义一些资源，他们将拥有这些方法”。这是一个微妙但至关重要的区别，当给定一个 URI 时，任何人都知道他们可以通过预定义与之交互一套方法和接收标准作为回报的 HTTP 响应。所以给定 http://www.peej.co.uk/我知道我可以在其上发出 GET 并接收一些有意义的东西回来。那我可以尝试对其进行 PUT 更改并收到有意义的 HTTP 错误代码因为我无权干涉用它。

【问题讨论】：

标签： web-services soap rest

【解决方案1】：

REST 和 SOAP 不是等价的概念。

休息：

取决于一种传输协议 (HTTP)。
充分利用该协议的特定功能（动词 GET、POST、PUT、DELETE、缓存、标头和预定义的错误代码）。
没有说明来回传递消息的格式。但是，由于 HTTP 动词和 URL 已经定义了要执行的操作，因此消息正文必须只包含数据。
消息安全性由传输协议 (HTTPS) 提供，并且仅是点对点的。如果您想端到端地保护消息，您必须自己做。
最初用于对对象进行简单的 CRUD 操作。

肥皂：

独立于传输协议（可以是 HTTP、FTP、TCP、UDP、命名管道、共享内存甚至电子邮件）。
仅要求传输协议能够发送和接收文本（例如，在 HTTP 上，仅使用 POST 动词）。
严格定义来回传递消息的格式。 SOAP 消息包含数据、对其执行的操作、标头以及失败时的错误详细信息。
消息安全性由 WS-* 标准提供，并且是端到端的。
最初用于任意 RPC 调用。

以上列表中的第 2 项和第 3 项是不兼容的要点。

【讨论】：

-1 for REST 依赖于 HTTP 并且“消息正文必须只包含数据”——嗯，HATEOAS 另有说明，CRUD 与 REST 正交。
@Doug：消息正文确实只包含数据；我故意避免指定什么样的数据。我也说过 REST 可以用于 CRUD 操作，而不是 REST = CRUD。我的回答并不是要详细解释 REST 或 HATEOAS，而只是列出它们与 SOAP 的不同之处。
我可以理解不深入，我认为一开始它们不是等效的概念是正确的。也许有更好的方法来对比它们——尤其是不要说 REST 只是一种协议，而 SOAP 是独立于协议的。例如，您可能更愿意说 REST 是一种利用传输协议的架构约束，而 SOAP 通过它建立隧道。
+1。 SOAP 是一种协议，而 REST 是一种架构风格
@Kishan：当我想要传输协议独立性、端到端加密或 RPC 样式的 API 时，我会使用 SOAP。对于其他一切，您可以使用 REST。

【解决方案2】：

SOAP 遵循 RPC 模式。 SOAP API 描述了一系列方法及其参数和返回值，您可以从代码中调用这些方法。有一个编组步骤将其转换为它的网络表示。

REST 绝不是 RPC。 REST API 描述了一系列资源，以及一组可以作用于它们的动词（通常是 HTTP 的 GET、POST、PUT、DELETE）。

直接回答您的问题：SOAP 主要违反了第 6 点（它不提供跨 API 的统一动词集）。它还违反了第 2 点（服务器可以为每个客户端维护状态），因此也违反了第 3 点（状态阻止缓存）。

【讨论】：

SOAP 可以是 ReSTful。仅仅因为 SOAP 允许不安定的事情（以及安宁的），并不意味着它不能安宁。
@Physics-Compute 并非如此。 SOAP 始终使用 HTTP POST，请求包含在正文中。您不能使用其他 HTTP 动词，这与 REST 背后的想法背道而驰。（不可缓存、非统一接口、非 HATEOAS 等）您可以在 SOAP API 中封装一个 RESTful API，但 SOAP 协议本身不能是 RESTful。
仅仅因为它只使用一个动词并不意味着它不合格。它当然是可缓存的，并且可能具有统一的接口。同样，仅仅因为它有能力不平静并不意味着它不能。该协议允许它存在或不存在。这就是问题所在。
@Physics-Compute 根据 Fielding，使用多种标准化方法是一项要求。虽然您可以在 SOAP 中模拟 REST 样式的接口，但我认为它仍然不能满足“统一接口/HATEOAS”的要求。充其量，这将是一项学术活动，与用户的期望背道而驰。 REST 的优点之一是它与 Web 的其余部分共享相同的超媒体界面。无论您做什么，我都无法从浏览器的地址栏中进行 SOAP 调用。见：whatisrest.com/rest_constraints/uniform_contract_profile

【解决方案3】：

REST 的目标之一是可缓存性，因为资源需要通过 uri（查询字符串）来标识。在soap中发布请求，因此对于不同的请求，您具有相同的uri，因此资源不能由ur唯一标识

【讨论】：

这并不意味着它不能被缓存。您可以通过 uri + 发布的数据进行缓存。不同风格的缓存当然可以，但仍然可以缓存。

【解决方案4】：

REST 仅符合 http 协议。

【讨论】：

【解决方案5】：

宁静： REST 是使用 HTTP 协议构建 Web 服务的架构风格，其中 Web 服务被视为资源，并使用一些基本的 HTTP 方法，如 GET、POST、DELETE 确定对资源的标准行动。 RESTful Web API（也称为 RESTful Web 服务）是使用 HTTP 和 REST 原则实现的 Web API。

肥皂： SOAP，最初定义为简单对象访问协议，是一种以 XML 形式交换结构化信息的协议规范。

【讨论】：

【解决方案6】：

SOAP 与 REST Web 服务

1) SOAP 是一种协议，而 REST 是一种架构风格。

2) SOAP 不能使用 REST，因为它是一种协议，而 REST 可以使用 SOAP Web 服务，因为它是一个概念并且可以使用任何协议，例如 HTTP、SOAP。

3) SOAP 使用服务接口来公开业务逻辑，而 REST 使用 URI 来公开业务逻辑。

4) SOAP 定义了要严格遵循的标准，而 REST 并没有像 SOAP 那样定义太多的标准。

5) SOAP 比 REST 需要更多的带宽和资源，而 REST 比 SOAP 需要更少的带宽和资源。

6) SOAP 定义自己的安全性，而 RESTful Web 服务从底层传输继承安全措施。

7) SOAP 只允许 XML 数据格式，而 REST 允许不同的数据格式，例如纯文本、HTML、XML、JSON 等。

RESTful Web 服务比 SOAP Web 服务更受欢迎。

【讨论】：

【解决方案7】：

SOAP 协议： SOAP 是一种协议，这意味着它具有定义的结构。

POST ：SOAP 请求始终需要 HTTP 正文，因此 HTTP 方法是 POST。更多关于未来 POST 中的 HTTP 方法（这些在 REST 中非常相关），但现在让我们假设在 SOAP 的情况下这始终是 POST
SOAP 操作：空表示，意图在 HTTP 请求 URI 中。
Content-Type : SOAP 使用 XML 作为通信语言，因此它始终是 text/xml
需要带有 XML 命名空间 (xmlns) 以指示这是一个 SOAP 请求。
是描述请求和响应的根 SOAP 元素。

RESTful API 设计涉及在资源方面破坏系统，并通过在 Web 服务的基本 uri 上定义的端点（也称为操作）提供对这些资源的访问。访问是使用标准 HTTP 方法完成的，并由身份验证机制控制。资源的配置是通过请求和响应来提供和获取的，其中 HTTP 状态代码传达了状态。 1. 资源是系统中存在的实体，被制作成 RESTful。例如，在博客网站的情况下，这些可以是博客、帖子和 cmets。 2. 端点或操作提供了一种可以访问这些资源的机制。例如，列出特定博客上所有博客文章的端点将是 /blogs/{blogId}/posts 上的 GET。 3. Base URIs 定义了资源通过端点可用的 web uri 位置。举一个真实的例子，对于谷歌博主来说，base_uri 是https://www.googleapis.com/blogger/v3。 4. HTTP 方法是 REST 的简单所在。在 RESTful API 设计中，对资源的操作是通过标准的 HTTP 方法完成的，主要是 GET、POST、PUT 和 DELETE。其他 HTTP 方法 - OPTIONS、HEAD、PATCH 在某些情况下也被使用。

【讨论】：