REST API和SOAP API之间的区别

浅浅的花香味﹌ 2022-04-24 15:18 210阅读 0赞

The Representational State Transfer (REST)架构风格不是可以购买的技术，也不是可以添加到软件开发项目中的库。REST是一种世界观，将信息提升为我们构建的体系结构的第一流元素。

Roy Fielding博士的论文“架构风格和基于网络的软件架构设计”介绍并整理了用于描述“RESTful”系统的思想和术语。这是一份学术文件，但通过提供RESTful架构的基础，可以理解和方便。

该方法的总结是，通过特定的架构选择，我们可以从我们创建的系统中获得理想的属性。这种架构风格中详细描述的约束是广泛适用的。

![REST API和SOAP API之间的区别][REST API_SOAP API]

Representational State Transfer是什么意思?以无状态的方式传输、访问和操作文本数据表示。当正确部署时，它在internet上的不同应用程序之间提供统一的互操作性。“无状态”这个术语是一个至关重要的部分，因为它允许应用程序以不一样的方式进行通信。

一个RESTful API服务通过统一资源定位器(URL)公开。这个逻辑名称将资源的标识与所接受或返回的标识分开。URL方案是在RFC 1738中定义的，在这里可以找到。

RESTful URL必须具有创建、请求、更新或删除的功能。这个动作序列通常被称为CRUD。要请求和检索资源，客户端将发出超文本传输协议(HTTP) GET请求。这是最常见的请求，每次在浏览器中键入URL并单击return、选择书签或单击锚点引用链接时执行。

对于与RESTful API的编程交互，可以使用十几种或更多的客户端API或工具。要使用curl命令行工具，可以输入以下内容:

$curl http://cloud-elements.com/elements-catalog/

这将返回命令行上的默认表示，但是，您可能不希望该表单中的信息。幸运的是，HTTP有一个内置的机制来过滤和返回不同格式的信息。如果服务器支持“接受”表示，则可以在标题和信息中指定此格式。这被称为内容协商，是HTTP中使用较少的一个方面。这种以不同形式请求信息的能力是可能的，因为资源的名称与其形式分离。尽管REST中的“R”是“表示”，而不是“资源”，但在构建允许客户以他们想要的形式询问信息的系统时，应该记住这一点。

基于rest的请求的一个重要方面是，每个请求包含足够的状态来响应请求。这就允许服务器上的可见性和无状态性、扩展系统所需的属性以及识别正在发出的请求。这种状态还允许缓存特定的结果。服务器地址和请求状态的组合，将计算散列键组合成结果集。

GET请求允许客户端发出非常特定的请求，但只在必要时。客户机可以在本地缓存结果，服务器可以远程缓存结果，或者某个中间体系结构元素可以在中间缓存结果。这是一个独立于应用程序的属性，可以设计到我们的系统中。

仅仅因为可以操纵资源，并不意味着每个人都有能力这样做。通过设置一个保护模型，该模型要求用户进行身份验证并证明他们可以在我们给他们许可之前做一些事情。

## **What About SOAP?** ##

简单明了，它们不是一回事。尽管您可以用任何一种方法解决许多架构问题，但它们并不是可以互换使用的。

这种混乱很大程度上源于一种误解，即REST“关于通过url调用Web服务”。这个想法与RESTful架构的功能根本不相符。如果没有对RESTful架构实现的更宏观的理解，很容易失去实践的意图。

REST最好用于管理系统，通过将产生和使用它的技术产生和使用的信息解耦。我们可以实现:

性能

可伸缩性

普遍性

简单

可修改性

可扩展性

这并不是说不能构建基于soap的系统来展示其中的一些属性。当由于技术、组织或过程复杂性而不能在单个事务的范围内维护请求的生命周期时，SOAP是最佳的利用方式。

## **Verbs** ##

![REST API和SOAP API之间的区别][REST API_SOAP API 1]

谓词是可以与服务器上的资源交互的方法或操作。在RESTful系统中，动词的数量有限，使人们对这种方法感到困惑和沮丧。看似任意的和不必要的约束，实际上是为了以非特定于应用程序的方式鼓励可预测的行为。通过明确和明确地定义这些动词的行为，客户可以在面对网络中断和失败时自主地做出决策。

有四个主要的HTTP动词是设计良好的RESTful系统使用的。

### GET ###

GET请求是Web上最常见的动词。GET请求将命名资源的表示形式从服务器传输到客户端。尽管客户机不一定知道它所请求的资源的任何信息，但是请求返回一个带有元数据标记的字节流，指示客户机应该如何解释资源。这通常是通过“text/html”或“application/xhtml+xml”在web上表示的。正如我们上面所指出的，只要服务器支持，客户端就可以使用内容协商来主动询问所请求的内容。

关于GET请求的一个关键点是，它不应该修改服务器端上的任何内容。这基本上是一个安全的要求。GET请求也是具有幂等性的。这意味着多次发出请求不会产生任何后果。这是基于网络的分布式基础设施中的一个关键属性。如果客户端在发出GET请求时被中断，那么由于动词的幂等性，它应该被授权再次发出请求。

在设计良好的基础设施中，客户机向哪个应用程序请求什么并不重要。总是会有特定于应用程序的行为，但是我们越能深入到非特定于应用程序的行为中，我们的系统就会越有弹性、更容易访问和更容易维护。

### POST ###

当客户端无法预测要创建的资源的标识时，将使用POST。当我们雇佣员工、下订单、提交表单等时，我们无法预测服务器将如何命名我们创建的资源。这就是为什么我们将资源的表示发布给处理程序(例如servlet)。服务器将接受输入、验证它、验证用户的凭据等。在成功处理之后，服务器将返回一个201个HTTP响应代码，其中有一个“Location”标头，指示新创建的资源的位置。

注意:有些人将POST视为对创建请求的对话GET。它们返回的不是201，而是创建了资源主体的200。这似乎是避免第二个请求的快捷方式，但它结合了POST和GET函数，同时增加了缓存资源的可能性。避免以牺牲大局为代价而走捷径的冲动。短期来看，这似乎是值得的，但随着时间的推移，这些捷径会累积起来，。产生不好的影响

### PUT ###

客户端可以向已知URL发出PUT请求，作为将表示传递回服务器的一种方式，以便执行覆盖操作。这种区别允许PUT请求具有幂等性，而POST更新不是。

如果客户端正在发出PUT覆盖并被中断，客户端可以再次发出PUT，因为覆盖操作可以重新发出，不会产生任何后果;客户机正在尝试控制状态，因此可以简单地重新发出命令。

注意:此协议级别的处理并不一定排除需要更高(应用程序级别)的事务处理，在体系结构上，它是希望在应用程序级别以下进行处理的属性。

### DELETE ###

DELETE在公共Web上没有广泛使用(谢天谢地!)，但是对于您控制的信息空间，它是资源生命周期中有用的一部分。

删除请求是具有幂等性的。删除请求可能会被网络故障中断。无论第一个请求是否成功处理请求，资源都应该使用204(无内容)响应代码进行响应。它可能需要一些额外的处理来跟踪以前删除的从未存在的资源和资源(应该返回404响应代码)。一些安全策略可能要求您返回一个404响应代码，以防止出现资源的泄漏信息。

### HEAD ###

HEAD用于在不实际检索资源的情况下发出请求。它是客户端检查资源是否存在并可能发现关于资源的元数据的一种方法。

### OPTIONS ###

OPTIONS还用于询问其他谓词是否适用于资源，从而询问服务器关于资源的情况。这使开发人员能够更好地理解如何针对资源进行交互和开发。

### PATCH ###

作为最新的动词，PATCH直到2010年才被作为HTTP的一部分正式采用。目标是提供一种标准化的方式来表示部分更新。标准格式的补丁请求允许交互对意图更加明确。

如果客户端发出一个带有If- match头的补丁请求，这个部分更新就有可能成为幂等性的。可以重试中断的请求，因为如果第一次成功，if - match头将与新状态不同。如果它们是相同的，则不处理原始请求，可以应用补丁。

## **Response Codes** ##

![REST API和SOAP API之间的区别][REST API_SOAP API 2]

HTTP响应代码提供了客户机和服务器之间关于请求状态的丰富对话。大多数人对一般意义上的200、403、404甚至500只比较熟悉，但是有更多有用的代码可以使用。每一组数字可分为以下几类:

1 xx:信息

2 xx:成功

3 xx:重定向

4 xx:客户端错误

5 xx:服务器错误

在RESTful中还有更多的东西需要学习，但是希望这文章里已经说明了一些基本内容。此外，当遇到其他RESTful架构时，您还可以更好地理解它。

[REST API_SOAP API]: /images/20220212/13a141856f8d4bd08f0490817d97e079.png
[REST API_SOAP API 1]: /images/20220212/904b429c75f848f7869e3680e2c17792.png
[REST API_SOAP API 2]: /images/20220212/e456284e145b4899bd7d5faf374b4d02.png