REST 与 SOAP 的区别
REST是API架构风格,SOAP是数据传输协议。REST用JSON,轻量高效,适合公共Web服务;SOAP用XML,安全合规,适用于企业级应用。二者特点不同,适用场景有别。
REST与SOAP:有何不同?
API是应用程序编程接口的缩写。API规定了不同的软件组件应该如何以编程方式进行交互和通信。
API的一种常见类型是Web API。Web应用程序(包括网站)向Web API或Web服务发送请求,以获取需要显示给用户的数据。想象一下,一个网站接收您的搜索条件,然后返回航班、酒店或汽车租赁的"最佳优惠"。这个网站并不是从其自己的数据库中检索这些数据,而是通过向专门处理航班、酒店等数据的API发送请求来获取数据。"Web" API指的是使用HTTP协议传输数据的API。
Web API最流行的两种规范是REST和SOAP。
围绕哪种架构风格最适合构建API存在争议。它们都是规范,但不能直接进行"苹果对苹果"的比较。细微的区别在于,REST是一种API架构风格,而SOAP是一种访问Web服务的协议。尽管它们看似竞争关系,但各自都有不同的适用场景。
本文将探讨这两种标准之间的差异,以及在何种情况下选择其中之一。
REST与SOAP:相似之处与差异
那么,REST和SOAP之间有什么共同点,为什么它们经常被拿来比较?REST和SOAP都是规范,为客户端如何访问和与Web服务及其公开的功能进行交互提供了标准。如前所述,REST是一种API架构风格,而SOAP是一种数据传输协议。
REST作为一种架构风格,对Web API的设计施加了特定的约束。REST标准要求被视为“RESTful”的Web API遵守REST约束。这些约束包括但不限于:客户端与API服务器分离、无状态性以及可缓存性。
SOAP作为一种Web API协议,是一种数据传输标准,它规定了消息的1)结构(格式)、2)发送方式(通信协议)以及3)处理方式(处理模型)。与SOAP不同,REST并未规定如何处理消息。
由于SOAP只是一种Web API协议,因此REST API可以选用SOAP协议作为其数据传输标准。然而,REST和SOAP是不同的标准,通常不会混用。
尽管一个是架构风格,另一个是协议,但两者都为API消息格式提供了标准。REST和SOAP的消息格式都是人类和机器可读的。对于REST而言,JSON是一种轻量级的数据交换格式,具有很高的浏览器兼容性。对于SOAP,XML是一种可扩展标记语言,允许使用自定义的描述性标签,便于阅读。这些数据格式将在后文进行更详细的讨论。
REST之前的SOAP
SOAP的出现早于REST。REST的设计旨在解决SOAP存在的一些问题。REST的目标是轻量级、高度浏览器兼容、实现客户端与服务器的分离,并提供实现缓存的能力。
那么,既然REST出现在SOAP之后,并且REST解决了SOAP的问题,为什么SOAP仍然存在?
尽管REST相比SOAP具有明显的优势,并且在某种程度上旨在取代SOAP,但SOAP仍有其适用场景。例如,SOAP适用于需要消息级别安全性的企业级应用。
REST 代表表述性状态传递,是一种特定的架构风格,被认为是“RESTful”的 API 都必须遵循其约束。RESTful API 必须具有 1) 统一接口,2) 无状态,3) 可缓存,4) 客户端与服务器分离,5) 分层系统,以及 6) 按需代码。REST API 是使用 HTTP 协议的 Web API,客户端向 API 服务器发送 HTTP 请求以获取数据,然后服务器将带有编码数据的 HTTP 响应发送回客户端。
客户端通过“资源”来访问和操作 REST API 暴露的数据。资源代表了不同的 API 功能,并通过资源 URL 进行访问。您可以将资源视为 API 返回的数据对象。发送请求时,您会向资源传递一个对应 CRUD(创建、读取、更新和删除)操作的方法。可以将这些方法视为对资源采取的“操作”,例如创建、更新或删除资源。
例如,知名的 Swagger Petstore API 就包含多个资源。这些资源包括 Pet、Store 和 User。它们都围绕宠物商店这一核心主题,但各自代表了您可以创建、操作或删除的不同数据对象。
要请求一个资源,您需要向该资源的唯一 URL 发送一个 HTTP 请求,并指定要对资源执行的操作(方法)。示例操作包括创建、更新、检索或删除资源(分别对应 POST、PUT、GET 和 DEL 方法)。
客户端-服务器分离的优势
客户端组件与服务器组件分离具有以下好处:
所有组件都具备可移植性。 由于用户界面与服务器分离,因此可以移植到许多平台。服务器组件具有可移植性,因为REST架构是“多层”的。REST API可以跨平台适应,便于在开发期间进行测试。
通过限制架构层之间的交互来提升可扩展性(多层架构)。这种限制简化了服务器组件。此架构还提高了在服务器之间迁移数据和快速推出新更改的灵活性。
更易于集成。 REST允许开发人员更多地关注用户界面、功能和业务规则,而不是由API服务器处理的服务器组件和数据管理。
支持JSON消息格式
REST使用JSON作为数据格式具有以下几个优点:
- 浏览器兼容性 – JSON作为一种数据格式与浏览器兼容性非常好,并且对浏览器更友好。
- 占用更少带宽 – JSON是一种极其轻量级且易于解析的数据格式。XML负载(在SOAP的情况下)比JSON更大。更大的负载需要更多带宽。编写XML SOAP请求所需的代码量也增加了消息大小。
消息格式的灵活性
除了JSON之外,REST还提供更多消息格式,如HTML、纯文本、XML、YAML等。消息格式的灵活性使得REST对于公共API特别有益。
SOAP是服务对象访问协议的缩写。根据SmartBear的说法,它是一种“基于标准的Web服务访问协议”。换句话说,它是客户端和API服务器之间来回传输数据的协议。SOAP的主要目标如下:
- SOAP使用结构化且可扩展的消息格式——XML
- SOAP使用多种通信协议——HTTP、SMTP、TCP等
- SOAP独立于Web API的实现语言
SOAP使用XML作为其数据格式。XML代表可扩展标记语言。根据Mozilla的说法:
“XML是一种类似于HTML的标记语言,但没有预定义的标签可供使用。相反,您可以定义专门为您的需求设计的标签。”
XML允许您使用自描述标签而不是像HTML那样的预定义标签来存储和共享信息。XML是标准化的,因此可以在不同平台和系统之间高度移植。XML作为一种消息格式非常可定制。您可以定义XML模式来验证XML有效负载的结构,以确保它们符合要求。
客户端访问和操作SOAP API公开数据的方式与REST API不同。REST允许客户端使用资源URL访问“数据”。而SOAP则涉及访问操作数据的API“函数”。
与REST不同,请求中不包含方法(CRUD操作)。相反,单独的函数处理对同一数据对象的CRUD操作。例如,REST API可能有一个端点(URL),通过在请求中传递POST或PUT方法来创建或更新资源。使用SOAP创建或更新数据对象需要将创建或更新请求发送到处理这些特定CRUD操作的单独函数。
XML 消息的主要传输方式是使用 HTTP 或 HTTPS 协议。然而,SOAP API 也可以使用传输控制协议 (TCP)、简单邮件传输协议 (SMTP) 和用户数据报协议 (UDP) 来发送数据。而 REST 仅支持 HTTP 协议。
SOAP 的优势
更安全
💛🧡🧡客户评价:Baklib集中信息,简化我们不断发展的产品的更新,并简化将复杂的流程转化为我们团队易于访问的资源。Baklib确实我需要的一切,甚至更多。
SOAP 非常适合对安全性要求高的 Web 服务,因为它使用 WS-Security(与 SSL 结合)并内置 ACID 合规性。REST 则不具备这些特性。WS-Security 是关于 SOAP XML 消息如何签名和加密的规范。每个 SOAP 请求的 Header 块都包含完成请求所需的安全信息。ACID 合规性是一套保护数据库完整性的标准。许多企业级和金融交易应用程序都需要 ACID 合规性。
灵活的传输通道
SOAP 支持多种通信协议。REST 仅支持 HTTP。使用 SOAP,您可以选择 HTTP、HTTPS、用户数据报协议 (UDP)、传输控制协议 (TCP) 或简单邮件传输协议 (SMTP)。
REST 消息的构成
一个 REST 消息包含以下组成部分:
- 方法 – 针对资源执行的CRUD操作。在此情况下,HTTP POST方法表示创建操作。
- 端点 – 指向特定资源的端点(资源URL)。在此情况下,端点是 https://petstore.swagger.io/v2/pet。资源是由API返回的数据对象,可以通过端点进行定位。
- 头部 – 指定消息格式,在此情况下为JSON。您可以在请求的头部传递授权凭据,例如API密钥。
- 请求体 – 包含一个JSON对象,该对象包含要赋予新资源的属性。在此情况下,请求体包含新宠物的详细信息。请求体类似于参数,不同之处在于它是包含多个属性的对象,而非单一属性。
以下是一个指向Swagger Petstore API的REST API cURL请求,用于创建宠物。
SOAP消息的结构
SOAP XML消息包含以下“块”:
- Envelope – 必需的部分,用于将 XML 消息标识为 SOAP 消息(区别于其他 XML 消息)。命名空间属性指向 SOAP 的最新版本。
- Header – 可选部分,用于存储授权属性,如 API 密钥等。
- Body – 必需的部分,指定在请求提交后期望从 API 接收到的信息。此部分包含函数名(过程)以及希望传递的、会影响结果的参数。在响应中,Body 部分包含 API 的响应及所请求的信息。
- Fault – 可选部分。如果 SOAP API 无法处理请求,它将发送在此定义的错误消息。请求失败的原因有很多,例如,消息结构可能不符合 XML 模式定义。
为了理解 SOAP 的结构,让我们将 REST 消息与 SOAP 消息进行比较。以下是向 Swagger Petstore API 发送的 REST API cURL 请求,用于根据 petId 检索宠物。petId 1 是包含在请求资源 URL 末尾的路径参数。
以下是相同请求的 SOAP 等效形式,以展示差异。
以下是一些区别:
-
消息格式:
- REST – cURL是用于编写HTTP请求的语言。但是,您可以使用任意数量的语言发送REST请求。消息有效载荷(消息体)是JSON格式。
- SOAP – 消息格式是XML。XML结构由XML模式强制执行。
-
方法(CRUD操作):
- REST – 请求中提供了GET方法,指示API检索某些内容。
- SOAP – 请求中不提供方法。请求被发送到处理检索的过程(GetPet函数)。
-
参数:
- REST – 宠物的ID作为路径参数在端点URL中传递。
- SOAP – 宠物的ID在Body块中使用GetPet选项传递。
何时使用REST与SOAP
REST适用于公共Web服务
REST和SOAP的特性使它们适用于不同的用例。
REST的一个定义性特性是其消息格式JSON。REST使用JSON使其非常适合公共Web服务/开放API。与SOAP的XML有效载荷相比,JSON有效载荷更轻量级且更小。JSON具有高度的浏览器兼容性,并且比XML对Web浏览器更高效。此外,JSON有效载荷包含的字符远少于SOAP有效载荷,因为XML消息比JSON更冗长。
由于SOAP XML负载在构建时也有更多开销,首选方法是在编程语言中集成SOAP库来发起API调用。虽然这被证明更高效,但它增加了另一层抽象,而在使用REST时则无需此抽象。REST的客户端-服务器分离约束不鼓励使用客户端库。客户端-服务器分离对于Web服务至关重要,因为它们必须可移植、可扩展并能独立演进。除了使用客户端库外,您还需要在客户端使用XML解析器,这会增加开销。
Web服务的一个关键问题是资源限制。虽然REST API不直接处理此问题,但客户端可以有效地缓存HTTP响应。缓存之所以可能,是因为REST使用URL分离端点,并使用HTTP头来执行CRUD操作。
SOAP则不同。当向SOAP API发送负载时,所有请求都指向一个URL。每条消息的HTTP头都是POST头。大多数HTTP缓存不缓存POST响应,使得SOAP无法(或不可行)进行缓存。无法为SOAP实现缓存,对于开发Web服务的人来说是一个缺点。
虽然REST带来了速度和效率,但它不支持像SOAP那样的消息级安全性。当需要此特性时,API开发者可能会选择REST而非SOAP。
SOAP用于企业应用程序
虽然对于Web服务(尤其是公共Web服务)来说,REST是总体上的最佳选择,但SOAP具有REST所缺乏的内置WS-Security。SOAP更适合对安全性要求苛刻的应用程序。与REST不同,SOAP的安全性是消息级的。
这额外增加的安全层使其非常适合企业级软件,例如CRM解决方案、身份管理、银行应用程序、金融和电信服务,或遗留系统。
SOAP内置了ACID合规性,这使得SOAP对敏感的金融服务具有吸引力。
另请阅读: gRPC 与 REST:有何不同?
SOAP 和 REST 的替代方案
除了 SOAP 和 REST,还存在一些替代方案。最常见的是 gRPC 和 GraphQL。
gRPC 代表远程过程调用。该标准适用于在带宽受限场景下需要轻量级消息传递的微服务架构。您可以使用 gRPC 将智能手机等物联网设备连接到后端服务。
GraphQL 是一种日益普及的数据库查询语言。从 GraphQL API 请求数据比 REST 更高效。对于 REST,有多个(有时是数百个)独立的资源 URL 来公开 API 的功能。如果您需要从两个资源收集信息,则必须向每个资源 URL 发出请求。而使用 GraphQL,所有 API 数据都可通过一次请求进行查询。客户端使用过滤器来缩小查询范围,从一个 API 检索数据。
结语
REST 和 SOAP 都是规范,为客户端如何访问和与 Web 服务及其公开的功能进行交互提供了标准。然而,REST 是一种 API 架构风格,而 SOAP 是一种用于客户端与 Web 服务器之间数据传输的协议。因此,将两者进行比较并非“同类对比”。
REST的出现是为了改进SOAP的局限性。REST的优势使其非常适合资源受限的公共Web服务。REST的数据格式JSON与浏览器高度兼容,并且比SOAP XML负载需要更少的带宽。REST还强制要求客户端-服务器分离。这一约束对于Web服务高效运行至关重要。虽然在某些方面,REST已经取代了SOAP在公共Web服务中的地位,但对于企业级应用和金融服务等安全敏感的场景,SOAP仍然被广泛采用。