SOAP和REST，也许您已经很熟悉它们，希望扩展您的知识或获取新的观点。或者，也许您听说过它们，并正在寻求更好的理解。毕竟，SOAP和REST已建立完善，其定义和规范可以追溯到几十年前。
请允许我帮助描述，比较以及以其他方式阐明这两种重要的Web服务和Web API设计方法。我还将重点介绍与这些方法相关的一些测试挑战以及如何解决它们。首先，让我们定义它们是什么以及它们与万维网的关系。
简介
万维网联盟（W3C）为全球范围内的互连资源（我们称为万维网）推荐了标准和协议。在“Web”地址访问“Web”资源，并通过“Web”协议进行传递。
当有人阅读此博客文章时，您可能知道您正在阅读浏览器地址栏中显示的URI上的HTML文档，该文档是使用HTTP（S）协议请求并发送的。W3C定义了使您能够阅读此博客文章的相同技术如何促进软件系统之间的通信。特别是，W3C定义了“Web服务”，这导致了多年来的许多其他标准和技术的创建。让我们从高层次看一下它们是什么。
SOAP
|
简单对象访问协议（SOAP Simple Object Access Protocol）是一种面向对象的协议，通过该协议，对象在客户端和服务器之间进行交换，并与XML进行串行化。SOAP规范建立在W3C定义的其他“Web”技术之上，包括XML和HTTP。许多规范都基于或扩展了SOAP规范，包括一些不是那么“简单”的规范。SOAP服务与SOAP客户端交换SOAP消息。SOAP消息也称为“信封”。SOAP信封有一个“Body”元素和一个可选的“Header”元素。“正文”通常会包装或从字面上“包围”另一个XML文档。SOAP请求还指示正在调用的操作或动作。不同的操作接受并返回不同类型的文档。
|
REST
|
代表性状态转移。与SOAP不同，REST不是一种特定的技术，而是一种体系结构样式，它定义了软件系统的特定约束。符合REST的Web服务或Web API通常被称为RESTful API或REST API。REST API的目的是交换资源的表示形式。资源可以是可以在概念上由URI标识的任何种类的实体。REST API侦听带有子路径的基本URI，以访问API公开的每个资源。资源路径可以包括一个或多个可用于标识资源的参数，其中某些路径段可能包含标识符。资源参数也可以采用查询参数或标头的形式。REST API公开了一个或多个CRUD操作以检索或操纵资源（创建、检索、更新和删除）。
|
现在，让我们深入研究一些细节，了解这些方法之间的比较。
运作方式
SOAP服务定义了一组操作。这些操作可以是任意的，因为所定义的操作的范围或目的没有限制。操作具有签名，通常代表信封的Body元素中元素的完全限定名称。例如，元素的名称可能是“calculateSomething”或“doSomethingFun”。
REST API对每个资源都有一组操作。可用的操作仅限于CRUD（创建、检索、更新和删除）。这些操作映射到HTTP方法，例如GET，POST，PUT，PATCH和DELETE。
基础对比
SOAP
|
SOAP操作提供了更高的灵活性，因为它们不仅限于CRUD，而且不必围绕诸如REST之类的特定资源类型进行构造。但是，操作也可以用于CRUD，其中SOAP主体中的XML可以包括对象的XML表示及其标识符。
|
REST
|
REST操作提供了更高的简便性。URI用于标识资源，该资源与正在交换的资源的表示形式分离。另外，操作必须是无状态的，这意味着这些操作以一致的方式运行，而不是基于客户端和服务端点之间的会话状态。
|
关键对比
SOAP
|
通过支持任意操作并可能跟踪状态，SOAP服务可以具有更高的复杂性。一个示例可以是具有“addToCart”操作的书店服务。每当客户致电“addToCart”时，服务就会跟踪客户购物车中的商品。其他客户可以调用“addToCart”，而不会影响其他客户的购物车。该服务分别跟踪每个客户端的状态。
|
REST
|
通过将操作限制在CRUD上，REST API比SOAP更受限制。另外，客户有跟踪自己状态的负担。在书店示例中，客户需要知道其购物车的ID，以便它可以为其购物车构建正确的URI，例如“cart/{id}”。客户端可以在该URI上执行GET来获取其购物车的结构化表示。客户端也可以在相同的URI上执行PUT，以使用更新的表示形式更新其购物车。
|
数据表示
SOAP消息传递涉及称为SOAP信封的XML文档的交换。SOAP信封包含一个“Body”元素和一个可选的“Header”元素。“Body”元素中的XML可以是任意的，但通常表示一个或多个实体或对象。内容类型是“text/xml”还是“application/soap+xml”，具体取决于是否遵循SOAP版本1.1或SOAP版本1.2。SOAP中的XML元素还可以用于包装其他类型的数据（文本或二进制）。W3C定义的称为“XOP”和“MTOM”的方法描述了如何将XML和SOAP消息中的二进制数据有效地打包为MIME“Multipart/Related”，从而避免了直接在XML标签中对二进制数据进行base64编码的需求。
REST API消息传递涉及资源表示形式的交换。“表示”可以是任何数据格式。它可以是结构化的数据交换/交换格式，例如XML或JSON，也可以是完全不同的格式，例如PDF或JPEG。没有内容类型限制。REST API可以支持多种数据格式或针对不同资源的不同数据格式。
基础对比
SOAP
|
XML是标准化的且易于理解，由各种W3C建议定义。XML具有名称空间的概念，该名称空间有助于消除元素歧义，避免命名冲突。SOAP信封提供了一层封装，使“Header”元素下可以包含其他元数据。
|
REST
|
REST API可以使用的数据格式不受限制。对于结构化数据，JSON的使用很普遍，并且使用和生成的速度比XML快得多。但是，还有其他序列化结构化数据的格式比JSON更为紧凑和高效，例如BSON（二进制JSON）或Google的协议缓冲区（Protobuf）。任何内容类型都是可能的。
|
关键对比
SOAP
|
与其他数据格式相比，XML也可能变得冗长或肿，同时产生和使用的序列化成本相对较高。但是，可以使用诸如“Content-Encoding: gzip”HTTP压缩方案之类的压缩来减小消息大小。通过使用替代或二进制XML编码，例如Microsoft的XML .NET Binary Format，可以降低序列化成本。
|
REST
|
REST API没有标准的数据交换格式。因此，您可能需要一组不同的库来使用和产生结构化数据，具体取决于要与之通信的REST API。但是，JSON非常流行并且经常可用。
|
可扩展性
SOAP和REST是可扩展的，但是方式非常不同。让我们深入比较一下。
基础对比
SOAP
|
协议绑定不必是HTTP，而可以是任何东西。SOAP消息可以通过其他一些基于TCP的协议（例如SMTP）发送，也可以通过UDP套接字发送，就像WS-Discovery和UPnP一样。微软的.NET WCF SOAP框架具有TCP和命名管道传输。诸如JMS（Java消息服务）或AMQP（高级消息队列协议）之类的事件驱动或消息排队接口也用于SOAP。
SOAP还允许使用不同的消息交换模式。它不必是请求答复的。它可以是异步的，单向的或一劳永逸的。SOAP用于面向服务的体系结构（SOA），其中服务被松散耦合、推送或响应企业服务总线（ESB）路由的消息。
|
REST
|
REST API是可扩展的，因为它们可能表示具有不同消息格式的资源。与SOAP不同，您不仅限于基于XML的表示形式。可以添加新资源而不影响现有资源。可以通过将某些版本号或版本标识符作为URI的一部分来对REST API进行版本控制。
|
关键对比
SOAP
|
具有更高可扩展性带来了更大的复杂性。考虑到可能使用的各种协议，消息传递模式和WS-*规范，没有唯一的方法来实现SOAP消息传递。
|
REST
|
REST API通常仅限于HTTP，其中方法和资源URI在HTTP请求标头中发送。但是，RESTful方法已经通过诸如约束应用协议（CoAP）之类的其他技术完成，该技术是针对物联网应用程序约束环境的REST实现。RESTful主体也可以在RabbitMQ和MQTT之类的消息传递代理中遵循，其中资源标识符和CRUD操作可以潜在地映射到消息目标或“主题”。
|
互通性
遵循开放标准，在设计SOAP时考虑到了互操作性，并不局限于任何特定的实现，平台或编程语言。但是，规范中的某些内容尚待解释。有些部分可能令人困惑，或者有错误、错别字或不良示例。这些问题源于简单的事情，例如：
-
是否应将特定值括在引号中。
-
某些XML构造是否可行还是应该避免。
-
SOAP主体中是否应允许或限制某些类型的事物。
另一个标准机构Web服务互操作性组织（WS-I）即将提供Web服务互操作性的准则。WS-I提供了各种互操作性配置文件。每个概要文件都有一个需求列表和一个断言列表，它们定义了如何检查需求。简而言之，WS-I概要文件说诸如“您应该这样做”和“您不应该那样做”之类的事情。有趣的事实：Parasoft是WS-I基本配置文件1.1测试断言文档（TAD）的撰稿人。
REST API可互操作，因为它们易于调用。有许多工具和API可以发出HTTP请求。流行的工具包括cURL和Postman。甚至网页上的简单表单都可以用来发出HTTP请求。除HTTP之外，REST API还通常使用各种开放标准，包括JSON之类的开放消息格式。REST API还可以实现各种开放性标准，以实现安全性和授权（稍后会详细介绍）。
基础对比
SOAP
|
SOAP在设计时就考虑了互操作性。W3C SOAP规范主要由Microsoft编写，Microsoft拥有自己的SOAP堆栈，该堆栈是作为Microsoft .NET Framework（最初是.NET Web服务增强（WSE）和后来的.NET Windows Communication Foundation（WCF））的一部分实现的。但是，可以从许多其他供应商处获得SOAP堆栈，包括像Apache项目这样的开源项目。除了.NET之外，SOAP堆栈也可用于不同的平台和编程语言，例如java，python和typescript。如果遵循相同的一组开放SOAP标准，则使用不同SOAP堆栈实现的SOAP客户端和SOAP服务就可以通信。
|
REST
|
REST API遵循KISS（“保持简单、愚蠢”）原则，遵循REST软件体系结构的一般设计原则。REST API易于调用，不一定需要复杂的软件堆栈，就像您通常需要与SOAP端点进行通信一样。
|
关键对比
SOAP
|
SOAP有许多扩展，通常称为WS-*。有WS-Addressing，WS-Policy，WS-Discovery，WS-MetadataExchange，WS-SecureConversation，WS-SecurityPolicy，WS-Trust，WS-Federation。WS-Security还具有各种相关规范，包括与XML和SOAP签名，XML和SOAP加密以及SAML（安全断言标记语言）相关的规范。清单不停地不断。SOAP服务很可能会遵循几种WS-*规范，从而增加了最初定义为“简单”协议的复杂性。您的客户必须遵循与该服务相同的WS-*标准，否则他们将无法正确通信。
|
REST
|
REST API不一定必须遵循开放标准。尽管JSON非常流行，但是没有标准的数据交换格式。任何内容类型都是可能的，包括可能的专有数据格式。此外，某些安全性或授权框架可能会带来额外的复杂性，需要在客户端进行兼容的实现。
|
安全性
安全性是SOAP和REST的重要考虑因素。当通过有线发送消息时，需要传输层安全性来对消息进行加密，以防止窃听。消息层安全性对于完整的端到端安全性是必不可少的，因此可以保护消息免受任何可能在到达目标位置之前对其进行访问的中介的攻击。需要身份验证或授权机制才能在客户端和服务器之间建立身份。
基础对比
SOAP
|
SOAP有大量的安全规范，称为WS-Security，由标准组织OASIS发布。除了HTTPS之类的传输层安全性机制之外，WS-Security规范还描述了如何将安全性直接嵌入SOAP消息本身（包括签名、加密数据）中，以及如何打包安全性令牌以建立诸如SAML（安全性声明标记语言）之类的身份。
|
REST
|
REST可以利用HTTP中的现有机制来实现安全性，包括SSL和基于HTTP的身份验证方案。还有一些开放的授权标准，包括OpenID Connect（OIDC），它基于OAuth和其他一些开放规范，例如JSON Web令牌（JWT）。
|
关键对比
SOAP
|
OASIS WS-Security规范很复杂。实现多个WS-Security和其他WS-*规范的服务给构建客户端带来了挑战。我需要什么钥匙？我是否需要对消息进行签名或加密？我应该使用哪种XML规范化算法？我是否需要首先获取SAML令牌并将其包含在SOAP标头中？我需要对消息的哪些部分进行签名和加密？
|
REST
|
消息层安全性不是标准的，有些是专有的。例如，Amazon AWS提供了服务器端和客户端机制来加密发送到其API或从其API发送的消息。
|
服务定义
SOAP服务和REST有多种类型的机器消耗性文档格式。服务定义文档支持自动化处理，例如为客户端或服务存根自动生成代码。服务定义文档也可以翻译成人类友好的文档格式，例如网页。
基础对比
SOAP
|
SOAP服务由WSDL描述，WSDL是W3C的另一个开放规范。WSDL是XML文档。它定义了用于请求、回复和故障消息的服务端点、操作和XML模式。
|
REST
|
REST API有多种服务定义格式。其中包括OpenAPI，RAML，API蓝图和WADL。它们都提供了不同的方式来描述REST API共有的事物，例如资源路径、参数、操作以及表示的类型和格式或模式。OpenAPI基于JSON Schema规范，可以表示为JSON或YAML。RAML文档基于YAML并支持JSON Schema和XML Schema（XSD）。API蓝图基于对象表示法的Markdown语法（MSON），并支持JSON模式。WADL是基于XML的W3C提交，支持使用XML Schema描述XML表示形式，这有点类似于WSDL for SOAP。
|
关键对比
SOAP
|
WSDL规范存在一些问题，这些问题由Web服务互操作性组织（WS-I）提供额外的说明和互操作性建议。WSDL也有多个版本。WSDL 1.1是最常实现的。WSDL 2.0（以前称为WSDL 1.2）未被包括Microsoft的.NET WCF在内的所有SOAP堆栈采用。有趣的是，WSDL 2.0引入了对描述REST API的支持。
|
REST
|
REST API没有标准的服务定义格式。但是，OpenAPI是作为标准的紧密考虑因素。OpenAPI最初由SmartBear开发为“Swagger”，后来以OpenAPI的形式捐赠给Linux基金会。该规范由OpenAPI Initiative监督，该组织的成员来自Google，IBM和Microsoft等大型公司。
|
每种服务定义格式都有其自己的代码和文档生成工具集合。这意味着您需要根据服务实现使用不同的工具集。但是，存在转换器，因此您可以将OpenAPI文档转换为RAML（反之亦然）。
我应该如何测试所有这些？
REST和SOAP提供了自己独特的权衡和挑战，尤其是在测试方面。要测试API，您需要能够构建客户端，发送输入数据，然后能够查看和验证返回的输出。
基础对比
SOAP
|
WSDL文档可以提供SOAP服务的完整描述，包括其安全要求。有各种可用的商业和开源工具，它们可以使用WSDL文档来自动生成用于测试SOAP端点的客户端。一个简单的示例是Microsoft的WCF测试客户端应用程序。
|
REST
|
REST API可以类似地提供服务定义文档，可以使用该文档来生成测试客户端。对于OpenAPI，Swagger UI提供了一个简单的Web界面来“试用”该API公开的每个操作。
|
关键对比
SOAP
|
SOAP服务可以使用HTTP以外的协议来实现，其中通信可能需要特定的消息传递接口（例如JMS）。各种WS-*协议都很复杂。免费和开源工具具有局限性，并且缺乏对所有传输和WS-*协议的支持。但是，Parasoft SOAtest通过全面支持SOAP和相关协议来帮助解决此问题。
|
REST
|
REST服务不一定具有服务定义。手动构建客户端可能很困难且繁琐，需要确定正确的API调用顺序以将它们串在一起以创建所需的场景。但是，Parasoft SOAtest可帮助解决此问题。除了能够从各种服务定义格式创建测试客户端之外，SOAtest的Smart API Test Generator还可以通过监视API调用并使用人工智能自动构建和配置测试方案来自动执行API测试创建。
|
你还在为此头疼吗？让Parasoft帮助。借助完整的端到端API测试解决方案Parasoft SOAtest，降低测试服务接口的成本、时间和复杂性。无论是SOAP，REST还是其他服务接口或技术，SOAtest都能满足您的要求。
不仅限于SOAP和REST？查看我们的“测试微服务”白皮书，以了解有关面向服务的体系结构的现代方法的更多信息。
标签：
本站文章除注明转载外，均为本站原创或翻译。欢迎任何形式的转载，但请务必注明出处、不得修改原文相关链接，如果存在内容上的异议请邮件反馈至chenjj@cahobeh.cn
彩票走势图 
10次
相关产品
最新文章 
彩票走势图相关的文章 
微信
在线咨询
渝公网安备
50010702500608号
客服热线