什么是 RESTful API？
RESTful API 是一种用于在两个计算机系统之间通过互联网安全交换信息的接口。在现代业务应用中，与其他内部和第三方应用程序通信以执行各种任务（例如生成月度工资单或与银行系统交互）是常见的需求。RESTful API 因其遵循安全、可靠且高效的软件通信标准，成为支持这种信息交换的关键技术。
API 基础：理解应用程序编程接口
应用程序编程接口 (API) 定义了软件系统之间进行通信时必须遵循的规则集合。开发者通常会公开或创建 API，以便其他应用程序能够以编程方式与他们的应用进行交互。您可以将 Web API 视为客户端与 Web 上资源之间的一座“网关”。
- 客户端 (Client)：指希望从 Web 获取信息的用户，它可以是人类用户，也可以是利用 API 进行通信的软件系统。
- 资源 (Resource)：指不同应用程序向其客户端提供的信息，这可以是图像、视频、文本、数字或任何类型的数据。提供资源的机器通常被称为 服务器 (Server)。组织通过使用 API 来共享资源并提供 Web 服务，同时保持数据安全性、控制权和身份验证机制。
REST 架构风格：原理与核心约束
表征状态转移 (Representational State Transfer, REST) 是一种软件架构风格，它为 API 的工作方式施加了一系列条件。REST 最初是作为管理复杂网络（如互联网）通信的指导原则而创建的。您可以利用基于 REST 的架构来支持高性能、可靠且规模化的通信。它易于实现和修改，为任何 API 系统带来了良好的可见性和跨平台可移植性。
遵循 REST 架构风格的 API 被称为 REST API。实现 REST 架构的 Web 服务则被称为 RESTful Web 服务 (RESTful Web Service)。通常，RESTful API 特指 RESTful Web API。然而，在日常交流中，您可以互换使用 REST API 和 RESTful API 这两个术语。
以下是 REST 架构风格的一些核心原则：
统一接口 (Uniform Interface)
统一接口是任何 RESTful Web 服务设计的核心。它要求服务器以标准格式传输信息。在 REST 中，格式化的资源被称为“表征”（representation）。这种表征格式可以与服务器应用程序上资源的内部表示不同。例如，服务器可以将数据存储为文本，但以 HTML 或 JSON 等格式发送其表征。
统一接口施加了以下四个架构约束：
- 资源识别：请求必须通过使用 统一资源标识符 (URI) 来识别资源。
- 自我描述消息：客户端在资源表征中应包含足够的信息，以便在需要时修改或删除资源。服务器通过发送描述资源的元数据来满足此条件。
- 超媒体即应用状态引擎 (HATEOAS)：客户端接收关于如何进一步处理表征的信息。服务器通过发送包含如何最好地使用这些信息的自描述消息来实现这一点。
- 超链接驱动：客户端收到完成任务所需的所有其他相关资源的信息。服务器通过在表征中发送超链接来实现这一点，以便客户端可以动态发现更多资源。
无状态性 (Statelessness)
在 REST 架构中，无状态性指的是一种通信方法，其中服务器独立于所有先前的请求完成每个客户端请求。客户端可以以任何顺序请求资源，并且每个请求都是无状态的或与其他请求隔离的。这种 REST API 设计约束意味着服务器可以在每次请求时完全理解并满足请求，无需保存客户端的会话状态。
分层系统 (Layered System)
在分层系统架构中，客户端可以连接到客户端和服务器之间的其他授权中介（如负载均衡器、缓存服务器等），并且仍然会收到来自服务器的响应。服务器也可以将请求传递给其他服务器。您可以设计 RESTful Web 服务在多个服务器上运行，这些服务器具有安全、应用程序和业务逻辑等多个层，协同工作以满足客户端请求。这些层对客户端保持不可见。
可缓存性 (Cacheability)
RESTful Web 服务支持缓存，即将一些响应存储在客户端或中介中以提高服务器响应时间的过程。RESTful Web 服务通过使用将自身定义为可缓存或不可缓存的 API 响应来控制缓存行为。
按需代码 (Code-On-Demand)
在 REST 架构风格中，服务器可以通过将软件编程代码传输到客户端来暂时扩展或自定义客户端功能。这是可选的约束。
RESTful API 的优势
RESTful API 具有以下显著优势：
出色的可扩展性 (Scalability)
实现 REST API 的系统可以高效地扩展，因为 REST 优化了客户端-服务器交互。无状态性消除了服务器保持会话状态的负担，从而降低了服务器负载。管理良好的缓存部分或完全消除了某些客户端-服务器交互，进一步减轻了服务器压力。所有这些特性都支持可扩展性，而不会导致降低性能的通信瓶颈。
卓越的灵活性 (Flexibility)
RESTful Web 服务支持完全的客户端-服务器分离。它们简化并解耦了各种服务器组件，以便每个部分可以独立发展。服务器应用程序的平台或技术更改不会影响客户端应用程序。分层应用程序功能的能力进一步增加了灵活性。例如，开发人员可以更改数据库层，而无需重写应用程序逻辑。
强大的技术独立性 (Independence)
REST API 独立于所使用的技术。您可以使用各种编程语言编写客户端和服务器应用程序，而不会影响 API 设计。您还可以更改任一侧的底层技术，而不会影响通信。
RESTful API 的工作原理
RESTful API 的基本功能与您浏览互联网的方式相似。当客户端需要资源时，它通过 API 联系服务器。API 开发者会在服务器应用程序的 API 文档中详细解释客户端如何使用 REST API。以下是任何 REST API 调用的常规步骤：
- 请求发起：客户端向服务器发送请求。客户端根据 API 文档，以服务器可以理解的方式格式化请求。
- 身份验证与授权：服务器验证客户端身份，并确认客户端有权发出该请求。
- 请求处理：服务器接收请求并在内部进行处理。
- 响应返回：服务器向客户端返回响应。响应包含告知客户端请求是否成功的信息，以及客户端请求的任何数据。
REST API 请求和响应的具体细节会根据 API 开发者设计的方式略有不同。
RESTful API 客户端请求详解
RESTful API 要求请求包含以下主要组件：
唯一资源标识符 (URI)
服务器使用唯一的资源标识符识别每个资源。对于 REST 服务，服务器通常通过使用 统一资源定位符 (URL) 来执行资源识别。URL 指定了资源的路径。URL 也被称为请求 端点 (Endpoint)，它清晰地向服务器指定客户端需要什么。
HTTP 方法 (Methods)
开发人员通常使用 超文本传输协议 (HTTP) 实现 RESTful API。HTTP 方法告诉服务器需要对资源执行什么操作。以下是四种常见的 HTTP 方法：
- GET：客户端使用 GET 访问服务器上指定 URL 处的资源。GET 请求可以被缓存，并且可以在 RESTful API 请求中发送参数以指示服务器在发送前过滤数据。
- POST：客户端使用 POST 向服务器发送数据，通常用于创建新资源。它们在请求体中包含数据表征。多次发送相同的 POST 请求会产生多次创建相同资源的副作用。
- PUT：客户端使用 PUT 更新服务器上现有资源，或者创建资源（如果不存在）。与 POST 不同，在 RESTful Web 服务中多次发送相同的 PUT 请求会得到相同的结果（幂等性）。
- DELETE：客户端使用 DELETE 请求删除资源。DELETE 请求会改变服务器状态。但是，如果用户没有适当的身份验证，请求会失败。
HTTP 头 (Headers)
请求头是客户端和服务器之间交换的元数据。例如，请求头指示请求和响应的格式（如 Content-Type），提供请求状态信息（如 Authorization），或者定义缓存行为（如 Cache-Control）等。
请求体数据 (Data)
REST API 请求可能包含 POST、PUT 和其他 HTTP 方法成功工作所需的数据。这些数据通常以 JSON 或 XML 格式放置在请求体中。
请求参数 (Parameters)
RESTful API 请求可以包含参数，这些参数向服务器提供有关需要执行操作的更多详细信息。以下是一些不同类型的参数：
- 路径参数 (Path Parameters)：指定 URL 中的细节，通常用于识别特定资源，如
/users/{id}中的{id}。 - 查询参数 (Query Parameters)：请求有关资源的更多信息或过滤条件，通常出现在 URL 的
?之后，如/products?category=electronics&limit=10。 - Cookie 参数 (Cookie Parameters)：快速验证客户端，服务器通过 HTTP Cookie 在客户端和服务器之间传递状态信息。
RESTful API 身份验证方法
RESTful Web 服务在发送响应之前必须验证请求。身份验证 (Authentication) 是验证请求者身份的过程。RESTful API 有以下几种常见的身份验证方法：
HTTP 身份验证 (Authentication)
HTTP 定义了一些可直接用于实现 REST API 的身份验证方案。
- 基本身份验证 (Basic Authentication)：客户端在请求头中发送用户名和密码。这些凭据通常使用 Base64 进行编码。
- 持有者身份验证 (Bearer Authentication)：指授予令牌持有者访问控制的过程。持有者令牌通常是服务器响应登录请求而生成的加密字符串（例如 JWT）。客户端在请求头中发送此令牌以访问资源。
API 密钥 (API Keys)
服务器向首次客户端分配一个唯一的生成值作为 API 密钥。每当客户端尝试访问资源时，它都使用唯一的 API 密钥来验证自身。API 密钥安全性相对较低，因为客户端必须传输密钥，使其容易受到网络盗窃，通常需要结合 HTTPS 使用。
OAuth
OAuth 结合密码和令牌，为任何系统提供高度安全的登录访问。服务器首先请求密码，然后要求提供额外的令牌来完成授权过程。它可以随时检查令牌，并且可以在特定范围和有效期内进行检查。OAuth 主要用于授权而非身份验证，但通常与身份验证流程结合使用。
RESTful API 服务器响应解析
REST 原则要求服务器响应包含以下主要组件：
状态行 (Status Line)
包含一个三位状态码，用于表示请求成功或失败。例如：
2XX代码表示成功，如200 OK(通用成功响应)、201 Created(POST 方法成功创建资源响应)。3XX代码表示重定向，如301 Moved Permanently。4XX代码表示客户端错误，如400 Bad Request(服务器无法处理的不正确请求)、404 Not Found(资源未找到)。5XX代码表示服务器错误，如500 Internal Server Error。
响应消息体 (Message Body)
响应体包含资源表征。服务器根据请求头中包含的 Accept 字段选择适当的表征格式。客户端可以请求 XML 或 JSON 格式的信息，这定义了数据如何以纯文本形式写入。例如，如果客户端请求名为 John 的人的姓名和年龄，服务器可能会返回如下 JSON 表征：'{"name":"John", "age":30}'。
响应头 (Headers)
响应还包含关于响应的头或元数据。它们提供关于响应的更多上下文信息，并包括服务器信息（Server）、编码类型（Content-Encoding）、日期（Date）和内容类型（Content-Type）等。
关于
关注我获取更多资讯
