SOAP 与 REST API：Web 服务之间的区别
伊利亚·霍尔
SOAP 和 REST API 之间的主要区别
- SOAP 代表简单对象访问协议，而 REST 代表表述性状态转移。
- SOAP 是一种协议，而 REST 是一种架构模式。
- SOAP 使用服务接口向客户端应用程序公开其功能，而 REST 使用统一服务定位器来访问硬件设备上的组件。
- SOAP 的使用需要更多的带宽，而 REST 则不需要太多带宽。
- 比较 SOAP 和 REST API，SOAP 仅适用于 XML 格式，而 REST 适用于纯文本、XML、HTML 和 JSON。
- SOAP 不能使用 REST，而 REST 可以使用 SOAP。
什么是肥皂？
SOAP 是在 REST 出现之前设计的协议。设计 SOAP 的主要思想是确保在不同平台和编程语言上构建的程序能够轻松地交换数据。SOAP 代表 简单对象访问协议.
什么是休息？
REST的 是专门为处理媒体组件、文件甚至特定硬件设备上的对象而设计的。任何基于 REST 原则定义的 Web 服务都可以称为 RestFul Web 服务。Restful 服务将使用常规 HTTP 动词 GET、POST、PUT 和 DELETE 来处理所需组件。REST 代表表述性状态转移。
SOAP 和 REST 之间的区别
每种技术都有自己的优点和缺点。因此，了解每种设计应在哪些情况下使用总是好的。本 REST 和 SOAP API 差异教程将介绍 REST 和 SOAP API 之间的一些主要差异以及您在使用它们时可能遇到的挑战。
以下是 SOAP 和 REST API 之间的主要区别
| SOAP | REST的 |
|---|---|
| SOAP 代表简单对象访问协议 | REST 代表表述性状态转移 |
| SOAP 是一种协议。SOAP 是根据规范设计的。它包含一个 WSDL 文件，该文件包含有关 Web 服务功能以及 Web 服务位置的必要信息。 | REST 是一种 Archi结构样式，其中 Web 服务只有遵循以下约束才能被视为 RESTful 服务：
|
| SOAP 不能使用 REST，因为 SOAP 是一种协议，而 REST 是一种架构模式。 | REST 可以利用 SOAP 作为 Web 服务的底层协议，因为最终它只是一种架构模式。 |
| SOAP 使用服务接口向客户端应用程序公开其功能。在 SOAP 中，WSDL 文件为客户端提供必要的信息，可用于了解 Web 服务可以提供哪些服务。 | REST 使用统一服务定位器来访问硬件设备上的组件。例如，如果有一个对象代表托管在 URL 上的员工数据，即 http://demo.guru99 ，则以下是可以访问它们的一些 URI。 |
SOAP 的使用需要更多的带宽。由于 SOAP 消息中包含大量信息，因此使用 SOAP 传输的数据量通常很大。
<?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV ="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle =" http://www.w3.org/2001/12/soap-encoding"> <soap:Body> <Demo.guru99WebService xmlns="http://tempuri.org/"> <EmployeeID>int</EmployeeID> </Demo.guru99WebService> </soap:Body> </SOAP-ENV:Envelope> |
REST 在向服务器发送请求时不需要太多带宽。REST 消息大多仅由 JSON 消息组成。下面是传递到 Web 服务器的 JSON 消息的示例。您可以看到消息的大小与 SOAP 相比较小。
{"city":"Mumbai","state":"Maharastra"}
|
| SOAP 只能使用 XML 格式。从 SOAP 消息可以看出，传递的所有数据都是 XML 格式。 | REST 允许不同的数据格式，如纯文本、HTML、XML、JSON 等。但传输数据的最首选格式是 JSON. |
何时使用 REST？
最有争议的话题之一是在设计 Web 服务时何时应使用 REST 或何时使用 SOAP。以下是决定何时应将 REST 和 SOAP API 技术用于 Web 服务的一些关键因素 在以下情况下应使用 REST 服务
- 有限的资源和带宽 – 由于 SOAP 消息内容较大且消耗的带宽更大，因此在网络带宽受限的情况下应使用 REST。
- 无国籍 – 如果不需要维护从一个请求到另一个请求的信息状态，则应使用 REST。如果您需要适当的信息流，即一个请求中的某些信息需要流入另一个请求，则 SOAP 更适合此目的。我们可以以任何在线购买网站为例。这些网站通常需要用户首先将需要购买的商品添加到购物车中。然后，所有购物车商品都会转移到支付页面以完成购买。这是一个需要状态功能的应用程序示例。购物车商品的状态需要转移到支付页面以进行进一步处理。
- 高速缓存 – 如果需要缓存大量请求，那么 REST 是完美的解决方案。有时，客户端可能会多次请求同一资源。这会增加发送到服务器的请求数量。通过实现缓存，最常见的查询结果可以存储在中间位置。因此，每当客户端请求资源时，它都会首先检查缓存。如果资源存在，则不会继续访问服务器。因此，缓存可以帮助最大限度地减少对 Web 服务器的访问次数。
- 编码简单 – 编写 REST 服务代码并随后实施比 SOAP 容易得多。因此，如果 Web 服务需要快速解决方案，那么 REST 就是最佳选择。
接下来在本 SOAP 和 REST 差异教程中，我们将学习何时使用 SOAP API。
何时使用 SOAP？
在以下情况下应使用 SOAP
- 异步处理并后续调用 – 如果要求客户端需要保证一定程度的可靠性和安全性，那么 SOAP 1.2 的新 SOAP 标准提供了许多附加功能，尤其是在安全性方面。
- 正式的沟通方式 – 如果客户端和服务器都对交换格式达成一致，那么 SOAP 1.2 为这种类型的交互提供了严格的规范。一个例子是在线购买网站，用户在付款之前将商品添加到购物车中。假设我们有一个负责最终付款的 Web 服务。可以有一个明确的协议，即 Web 服务只接受购物车商品名称、单价和数量。如果存在这种情况，那么最好使用 SOAP 协议。
- 有状态的操作 – 如果应用程序要求从一个请求到另一个请求需要维护状态，那么 SOAP 1.2 标准提供了 WS* 结构来支持这样的要求。
接下来，在 REST 与 SOAP API 的区别中，我们将了解 SOAP API 面临的挑战。
SOAP API 中的挑战
API 被称为 应用程式介面 并且由客户端和服务器提供。在客户端世界中，它由浏览器提供，而在服务器世界中，它由 Web 服务提供，可以是 SOAP 或 REST。
SOAP API 面临的挑战
- WSDL 文件 – SOAP API 面临的一个关键挑战是 WSDL 文档本身。WSDL 文档会告知客户端 Web 服务可以执行的所有操作。WSDL 文档将包含所有信息，例如 SOAP 消息中使用的数据类型以及可通过 Web 服务执行的所有操作。以下代码片段只是示例 WSDL 文件的一部分。
<?xml version="1.0"?>
<definitions name="Tutorial"
targetNamespace=https://demo.guru99.com/Tutorial.wsdl
xmlns:tns=https://demo.guru99.com/Tutorial.wsdl
xmlns:xsd1=https://demo.guru99.com/Tutorial.xsd
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace=https://Demo.guru99.com/Tutorial.xsd
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TutorialNameRequest">
<complexType>
<all>
<element name="TutorialName" type="string"/>
</all>
</complexType>
</element>
<element name="TutorialIDRequest">
<complexType>
<all>
<element name="TutorialID" type="number"/>
</all>
</complexType>
</element>
</schema>
</types>
根据上述 WSDL 文件，我们有一个名为“TutorialName”的元素，它是 String 类型，是元素 TutorialNameRequest 的一部分。
现在，假设 WSDL 文件根据业务需求发生变化，TutorialName 必须变为 TutorialDescript这意味着当前连接到此 Web 服务的所有客户端都需要在其代码中做出相应的更改，以适应 WSDL 文件中的更改。
这表明了 WSDL 文件的最大挑战是客户端和服务器之间的紧密契约，一个变化可能会对整个客户端应用程序造成很大的影响。
- 文档大小 – 另一个关键挑战是从客户端传输到服务器的 SOAP 消息的大小。由于消息很大，在带宽受限的地方使用 SOAP 可能会成为一个大问题。
接下来，在 RESTful 与 SOAP 的区别中，我们将了解 REST API 面临的挑战。
REST API 中的挑战
- 缺乏安全感 – REST 不会像 SOAP 那样强制实施任何类型的安全性。这就是为什么 REST 非常适合公开可用的 URL，但当涉及到在客户端和服务器之间传递机密数据时，REST 是用于 Web 服务的最差机制。
- 缺乏状态 – 大多数 Web 应用程序都需要有状态机制。例如，如果您有一个具有购物车机制的购物网站，则需要在实际购买之前知道购物车中的商品数量。不幸的是，维护此状态的负担落在了客户端身上，这只会使客户端应用程序变得更重且更难维护。
SOAP、CORBA、DCOM 之间的区别 Java RMI
远程访问技术，如 RPC（远程过程调用在 SOAP 和 REST API 出现之前，远程访问方法非常常用。下面提到了可用的各种远程访问技术。
- 科巴 – 这就是所谓的 Common O对象 R马术 B洛克人 A架构。建立该系统是为了确保在各种平台上构建的应用程序能够相互通信。CORBA 基于面向对象架构，但调用应用程序不必基于此架构。此技术的主要缺点是必须使用称为接口定义语言的单独语言进行开发，并且它只是提供了一种开发人员必须学习才能使用 CORBA 系统的额外语言。
- DCOM –这是 D分布式 C抱怨的 O对象 M模型，这是一个专有的 Microsoft 技术，以便客户端访问远程组件。这种机制的最大问题是，当不再需要资源时，客户端应用程序必须释放这些资源。其次，当客户端发送请求时，客户端必须确保以正确的方式包装或编组请求，以便 Web 服务能够理解发送的请求。另一个问题是，如果客户端应用程序是 Java 基于 DCOM 的应用程序（Microsoft 技术）需要额外的编码来确保用其他编程语言构建的应用程序可以与基于 DCOM 的 Web 服务一起使用。
- Java RMI - 作为。。而被知道 Java R表现感情 Method Invocation，这是 Java 如何通过远程过程调用来调用远程对象，这是该技术最大的限制是 Java RMI 只能在 Java 虚拟机。这意味着调用应用程序也必须在 Java 框架，以便利用 Java 马克斯米。
SOAP 与这些技术之间的主要区别如下
- 通过 HTTP 工作 – 所有 RPC 技术都有一个很大的限制，那就是它们不能通过 HTTP 协议工作。由于网络上的所有应用程序都必须使用此协议，因此这曾经是必须访问这些 RPC 样式 Web 服务的客户端的主要障碍。
- 使用非标准端口 – 由于 RPC 样式的 Web 服务无法通过 HTTP 协议运行，因此必须为它们打开单独的端口，以便客户端可以访问这些 Web 服务的功能。
