什么是 REST API？

📣 这篇文章最初以“什么是 REST API？”为题发表于The Bearer Blog上。

在使用 API 时，您可能会遇到REST或RESTful这两个术语。REST 代表“ Representational State Transfer”（呈现状态传输）。本质上，REST 是一组 API 可以遵循的建议。这使得 API 的设计更加简单，API 的使用也更加可预测。

但我们是如何走到这一步的呢？在 REST 出现之前，设计 Web API 的主要方法是使用简单对象访问协议 (SOAP)。REST 是一种架构风格，而 SOAP 是由万维网联盟 (W3C) 维护的官方标准化协议。SOAP 早期的吸引力，以及它最终的衰落，部分源于其标准的严格和冗长。SOAP 与 XML 绑定，包含安全和授权功能，并支持 HTTP 和 STMP 等多种协议。虽然这些特性对某些组织来说可能有益，但该标准带来的复杂性使得实施更加困难。

REST 的诞生是为了解决 SOAP 的诸多问题。REST 最初由 Roy Fielding于 2000 年定义，如今已成为开发 Web 服务最流行的方式之一。SOAP 是一项严格的标准，而 Fielding 的 REST 则是一种由六项指导性约束组成的架构风格。它并不依赖于 XML，尽管许多早期的 REST API 都使用了 XML。大多数当前的实现都使用 JSON。

REST 的六个指导约束

REST 的指导方针使 API 更加模块化和分层。正如 Fielding 所说：

REST 针对常见情况进行了优化，因此它应用于 Web 架构的约束也将针对常见情况进行优化。

开发人员可以添加所需的功能，同时仍保持一定的一致性。约束条件（无特定顺序）如下：

• 客户端-服务器：客户端和服务器独立运行。两者关注点明确分离，通过请求和响应进行通信。
• 无状态：每个请求都是独立的，它包含服务器理解该请求所需的所有信息。客户端可以保存会话状态，但服务器不存储任何上下文。
• 缓存：REST 的设计初衷是鼓励缓存，因此要求响应被标记为可缓存或不可缓存。这样，客户端就可以根据需要在将来的请求中重复使用响应。
• 统一接口：REST 的核心特性在于其接口。无论资源（数据）来自何处，都可以通过可预测且一致的接口进行访问。
• 分层系统：SOAP 在很大程度上是“全包式”的，而 REST 则允许以更加模块化、分层的方式构建 API。例如，API 入口点可以根据需要与身份验证服务器和数据源解耦。
• 按需代码（可选）：唯一可选的约束在 Web API 中很少见。按需代码允许 API 发送可执行代码作为响应。虽然在某些情况下这听起来很有吸引力，但考虑到 API 使用者可能使用的语言种类繁多，这不切实际。在现代应用程序中，这还会引发更多客户端安全问题。

虽然这些只是指导原则和约束，但它们并非固定的标准。这允许一些解读，但社区确实提供了像OpenAPI这样的解决方案，试图解决可能出现的一些不确定性。这也为身份验证等功能提供了更多选择。

工作原理

了解了一些基础知识后，我们来看看客户端和服务器如何使用 REST 进行交互。REST API 会暴露端点。这些端点是基于核心基本路径构建的唯一端点。例如：

基本路径可能如下所示：

https://api.example.com

端点可能看起来像：

/users
/user
/organizations/:id/teams
/profile

端点可以像上面一样用固定值定义/users，也可以通过更动态的路径定义，例如将/users/:idwhere:id替换为特定的用户 ID。此外，端点可以接受由属性和值组成的查询字符串，这些属性和值充当端点的指令。例如：/users?limit=10&order=ascending可能会请求按升序排列的 10 个用户列表。完整的资源路径最终看起来像这样：

https://api.example.com/users?limit=10&order=ascending
        ^^Base Path     ^^ Endpoint ^^Query String

然后，这些端点与一组HTTP 请求方法组合，以定义它们可以执行的操作。这些方法与“CRUD”应用程序的创建、读取、更新和删除动词相对应。端点关注的核心 HTTP 方法包括：

• GET：检索/读取数据。
• POST：创建新数据。
• PUT/PATCH：更新数据。
• 删除：删除现有数据。

GET 和 DELETE 可以与端点本身交互，但 POST 和 PUT/PATCH 能够在请求正文中发送数据。这通常是字符串化的 JSON 或表单数据。所有请求通常都包含一组用于描述请求的标头，例如Authorization、Content-Type等。

客户端通过端点将请求发送到服务器后，API 服务器会处理该请求，执行所需的操作并返回响应。此响应通常采用HTTP 状态代码和 JSON 对象的形式。

超越标准 REST

正如菲尔丁在其原始论文中所说：

REST 并不旨在捕获 Web 协议标准的所有可能用途。

RESTful Web 服务占据主导地位，但某些用例导致 API 的功能超出了 REST 所能提供的范围。流媒体、实时通信和数据密集型应用推动了不同类型的 API 的发展。

该领域最大的项目之一是 Facebook 的GraphQL。GraphQL被设计为 API 的统一查询语言，旨在为 API 使用者提供他们所需的数据，而不是可能包含多余内容的大型负载。

那么 REST 会消失吗？短期内不会。即使出现了新的方法和标准，你的大多数集成仍然会是 RESTful 的。如果你现在正在构建新的 API，REST 仍然是一个安全的选择，但或许值得考虑GraphQL、Falcor或gRPC等替代方案。

正在寻找一个解决方案，让您与 REST API 的交互更加可靠？ Bearer正是为此而生。立即试用，并通过@BearerSH联系我们。