soap协议_当SOAP遇上REST！一文解读Web服务Web API方法

当SOAP遇上REST！一文解读eb服务和Web API方法

SOAP和REST，也许您已经很熟悉它们，希望扩展您的知识或获取新的观点。或者，也许您听说过它们，并正在寻求更好的理解。毕竟，SOAP和REST已建立完善，其定义和规范可以追溯到几十年前。

请允许我帮助描述，比较以及以其他方式阐明这两种重要的Web服务和Web API设计方法。我还将重点介绍与这些方法相关的一些测试挑战以及如何解决它们。首先，让我们定义它们是什么以及它们与万维网的关系。

简介

万维网联盟(W3C)为全球范围内的互连资源(我们称为万维网)推荐了标准和协议。在“Web”地址访问“Web”资源，并通过“Web”协议进行传递。

当有人阅读此博客文章时，您可能知道您正在阅读浏览器地址栏中显示的URI上的HTML文档，该文档是使用HTTP(S)协议请求并发送的。W3C定义了使您能够阅读此博客文章的相同技术如何促进软件系统之间的通信。特别是，W3C定义了“Web服务”，这导致了多年来的许多其他标准和技术的创建。让我们从高层次看一下它们是什么。

当SOAP遇上REST！一文解读eb服务和Web API方法

现在，让我们深入研究一些细节，了解这些方法之间的比较。

运作方式

SOAP服务定义了一组操作。这些操作可以是任意的，因为所定义的操作的范围或目的没有限制。操作具有签名，通常代表信封的Body元素中元素的完全限定名称。例如，元素的名称可能是“calculateSomething”或“doSomethingFun”。

REST API对每个资源都有一组操作。可用的操作仅限于CRUD(创建、检索、更新和删除)。这些操作映射到HTTP方法，例如GET，POST，PUT，PATCH和DELETE。

基础对比

当SOAP遇上REST！一文解读eb服务和Web API方法

关键对比

当SOAP遇上REST！一文解读eb服务和Web API方法

数据表示

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遇上REST！一文解读eb服务和Web API方法

关键对比

当SOAP遇上REST！一文解读eb服务和Web API方法

可扩展性

SOAP和REST是可扩展的，但是方式非常不同。让我们深入比较一下。

基础对比

当SOAP遇上REST！一文解读eb服务和Web API方法

关键对比

当SOAP遇上REST！一文解读eb服务和Web API方法

互通性

遵循开放标准，在设计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遇上REST！一文解读eb服务和Web API方法

关键对比

当SOAP遇上REST！一文解读eb服务和Web API方法

安全性

安全性是SOAP和REST的重要考虑因素。当通过有线发送消息时，需要传输层安全性来对消息进行加密，以防止窃听。消息层安全性对于完整的端到端安全性是必不可少的，因此可以保护消息免受任何可能在到达目标位置之前对其进行访问的中介的攻击。需要身份验证或授权机制才能在客户端和服务器之间建立身份。

基础对比

当SOAP遇上REST！一文解读eb服务和Web API方法

关键对比

当SOAP遇上REST！一文解读eb服务和Web API方法

服务定义

SOAP服务和REST有多种类型的机器消耗性文档格式。服务定义文档支持自动化处理，例如为客户端或服务存根自动生成代码。服务定义文档也可以翻译成人类友好的文档格式，例如网页。

基础对比

当SOAP遇上REST！一文解读eb服务和Web API方法

关键对比

当SOAP遇上REST！一文解读eb服务和Web API方法

每种服务定义格式都有其自己的代码和文档生成工具集合。这意味着您需要根据服务实现使用不同的工具集。但是，存在转换器，因此您可以将OpenAPI文档转换为RAML(反之亦然)。

我应该如何测试所有这些？

REST和SOAP提供了自己独特的权衡和挑战，尤其是在测试方面。要测试API，您需要能够构建客户端，发送输入数据，然后能够查看和验证返回的输出。

基础对比

当SOAP遇上REST！一文解读eb服务和Web API方法

关键对比

当SOAP遇上REST！一文解读eb服务和Web API方法

你还在为此头疼吗？让Parasoft帮助。借助完整的端到端API测试解决方案Parasoft SOAtest，降低测试服务接口的成本、时间和复杂性。无论是SOAP，REST还是其他服务接口或技术，SOAtest都能满足您的要求。立即请求演示！

不仅限于SOAP和REST？查看我们的“测试微服务”白皮书，以了解有关面向服务的体系结构的现代方法的更多信息。

当SOAP遇上REST！一文解读eb服务和Web API方法

点击“了解更多”获取文中资料