SOAP vs 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？

SOAP 是一种在 REST 出现之前就设计的协议。设计 SOAP 的主要目的是确保用不同平台和编程语言构建的程序能够轻松地交换数据。SOAP 代表简单对象访问协议。

什么是 REST？

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 是一种架构风格，其中 Web 服务仅当其遵循以下约束时才可被视为 RESTful 服务：客户端-服务器无状态可缓存分层系统统一接口
SOAP 不能使用 REST，因为 SOAP 是一种协议，而 REST 是一种架构模式。	REST 可以使用 SOAP 作为 Web 服务的底层协议，因为归根结底它只是一种架构模式。
SOAP 使用服务接口将其功能暴露给客户端应用程序。在 SOAP 中，WSDL 文件为客户端提供了必要的信息，可用于了解 Web 服务可以提供哪些服务。	REST 使用统一服务定位符来访问硬件设备上的组件。例如，如果有一个对象表示存储在 URL http://demo.guru99 上的员工数据，则以下是一些可以访问它们的 URI： https://demo.guru99.com/Employee https://demo.guru99.com/Employee/1
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？

关于何时使用 REST 或何时在设计 Web 服务时使用 SOAP 是一个非常有争议的话题。以下是决定何时为 Web 服务使用 REST 和 SOAP API 技术的一些关键因素。REST 服务应在以下情况下使用：

资源和带宽有限 – 由于 SOAP 消息内容较重且消耗的带宽更多，因此在网络带宽受限的情况下应使用 REST。
无状态 – 如果不需要在请求之间维护信息状态，则应使用 REST。如果您需要正确的信息流，其中一个请求中的某些信息需要流向另一个请求，那么 SOAP 更适合此目的。我们可以以任何在线购物网站为例。这些网站通常需要用户首先将要购买的商品添加到购物车。然后，所有购物车中的商品都会被传输到付款页面以完成购买。这是需要状态功能的应用程序的一个示例。购物车商品的状态需要传输到付款页面以进行进一步处理。
缓存 – 如果需要缓存大量请求，那么 REST 是完美的解决方案。有时，客户端可能会多次请求相同的资源。这会增加发送到服务器的请求数量。通过实现缓存，最频繁的查询结果可以存储在中间位置。因此，当客户端请求资源时，它会先检查缓存。如果资源存在，它将不会连接到服务器。因此，缓存有助于最大限度地减少到 Web 服务器的往返次数。
编码简便 – 编码 REST 服务及其后续实现比 SOAP 容易得多。因此，如果需要快速高效的 Web 服务解决方案，那么 REST 是最佳选择。

在本次 SOAP 和 REST 区别教程的下一部分，我们将学习何时使用 SOAP API。

何时使用 SOAP？

SOAP 应在以下情况下使用：

异步处理和后续调用 – 如果客户端需要保证的可靠性和安全性级别，那么新的 SOAP 标准 SOAP 1.2 提供了许多附加功能，尤其是在安全性方面。
正式的通信方式 – 如果客户端和服务器都就交换格式达成协议，那么 SOAP 1.2 为这种类型的交互提供了严格的规范。例如，在线购物网站，用户在付款前会将商品添加到购物车。假设我们有一个执行最终付款的 Web 服务。可以有一个严格的协议，即 Web 服务只接受购物车商品名称、单价和数量。如果存在这种情况，那么最好使用 SOAP 协议。
有状态操作 – 如果应用程序要求在一次请求到另一次请求之间维护状态，那么 SOAP 1.2 标准提供了 WS* 结构来支持这些需求。

在本次 REST vs 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 必须变为 TutorialDescription。这意味着所有当前连接到此 Web 服务的客户端都需要在其代码中进行相应的更改，以适应 WSDL 文件的更改。

这显示了 WSDL 文件最大的挑战，即客户端和服务器之间的紧密合同，以及一项更改可能会对整个客户端应用程序产生重大影响。

文档大小 – 另一个关键挑战是从客户端到服务器传输的 SOAP 消息的大小。由于消息很大，在带宽受限的地方使用 SOAP 可能会带来大问题。

在本次 RESTful vs SOAP 区别教程的下一部分，我们将学习 REST API 的挑战。

REST API 的挑战

缺乏安全性 – REST 不像 SOAP 那样强制执行任何类型的安全。这就是为什么 REST 非常适合公开可用的 URL，但当涉及到客户端和服务器之间传递的机密数据时，REST 是用于 Web 服务的最糟糕的机制。
缺乏状态 – 大多数 Web 应用程序都需要有状态机制。例如，如果您有一个具有购物车功能的购物网站，在实际购买之前需要知道购物车中的商品数量。不幸的是，维护此状态的负担在于客户端，这只会使客户端应用程序更重且难以维护。

SOAP 与 CORBA、DCOM、Java RMI 的区别

在 SOAP 和 REST API 出现之前，远程访问技术（如 RPC（远程过程调用）方法）得到了广泛应用。下面列出了可用的各种远程访问技术。

CORBA – 这被称为通用对象请求代理体系结构。此系统旨在确保在不同平台上构建的应用程序能够相互通信。CORBA 基于面向对象的架构，但调用应用程序不必基于此架构。此技术的主要缺点是它必须使用一种称为接口定义语言的独立语言进行开发，这只是为开发人员提供了要学习的另一种语言才能使用 CORBA 系统。
DCOM – 这是分布式组件对象模型，是一项专有的 Microsoft 技术，供客户端访问远程组件。此机制的最大问题是，当不再需要时，由客户端应用程序负责释放资源。其次，当客户端发送请求时，由客户端确保请求被正确包装或编组，以便 Web 服务能够理解发送的请求。另一个问题是，如果客户端应用程序是 Java 基于的应用程序，需要使用 DCOM（Microsoft 技术），则需要额外的编码来确保用其他编程语言构建的应用程序能够与 DCOM Web 服务协同工作。
Java RMI – 称为 Java远程方法调用，这是 Java 在如何通过远程过程调用来调用远程对象方面的实现。此技术最大的限制是 Java RMI 只能在 Java 虚拟机上运行。这意味着调用应用程序也必须在 Java 框架中运行才能使用 Java RMI。

SOAP 与这些技术之间的主要区别如下：

通过 HTTP 工作 – 所有 RPC 技术都有一个主要限制，那就是它们不通过 HTTP 协议工作。由于 Web 上的所有应用程序都必须在同一协议上运行，这对于需要访问这些 RPC 风格的 Web 服务的客户端来说是一个主要的障碍。
通过非标准端口工作 – 由于 RPC 风格的 Web 服务不通过 HTTP 协议工作，因此必须为它们打开单独的端口，以便客户端可以访问这些 Web 服务的功能。