什么是 REST API？
REST API（即表现层状态转移应用编程接口）是一种架构风格，通常被视为设计和构建 Web 应用的标准。它提供了一组规则和约束，遵循这些规则和约束可以创建简单、可扩缩且易于集成的 Web 服务。
REST API 的定义
REST API 是遵循 REST 架构风格设计原则的 API。REST 以资源这一概念为核心，资源可以是任何信息，例如用户、产品、文档或多项内容的集合。
REST API 提供了一种方式，让客户端应用可以使用一组预定义的无状态操作来访问和操作这些资源。
REST API 的工作原理
1. 客户端发送请求
客户端应用（如移动应用、网络浏览器或其他服务器）向 API 发起请求以执行操作。此请求会发送到特定网址，其中包含 HTTP 方法、带有元数据的标头，有时还包含带有数据的请求正文。
2. 服务器处理请求
服务器接收并验证请求，确认客户端已通过身份验证并获授权执行所请求的操作。然后，它处理请求，这可能涉及从数据库检索数据、创建新资源，或更新现有资源。
3. 服务器发送响应
处理完请求后，服务器将响应发送回客户端。此响应包含一个 HTTP 状态代码，用于指示结果（例如，200 OK 表示成功，404 Not Found 表示资源不存在，401 Unauthorized 表示安全问题）。此外，响应正文中包含所请求的数据。
4. 数据传输
客户端和服务器之间传输的数据是资源状态的“表述”。JSON（JavaScript 对象表示法）是此类数据最常见的格式，因为它具有轻量化和人类可读等特点，并且易于被编程语言解析。
REST API 架构和组件
REST 的强大功能和可伸缩性源于一组指导其设计的架构约束。遵循这些约束的系统被认为是“RESTful”的。
资源
资源是 REST 中的一个基本概念。它是一个对象，具有类型、关联数据、与其他资源的关系以及一组对其进行操作的方法。例如，在电子商务 API 中，“产品”或“客户”就是资源。
URI（统一资源标识符）
每个资源都由一个 URI 唯一标识。设计良好的 API 使用清晰且一致的描述性 URI 来标识其资源。例如，/users 可能标识用户集合，而 /users/123 则标识 ID 为 123 的特定用户。
表述
客户端不直接与资源交互，而是与资源的表述交互。最常见的表述格式是 JSON，但也可以使用 XML 或 HTML 等其他格式。这提供了一种灵活的方式来表示资源的状态。
无状态
客户端向服务器发出的每个请求都必须包含服务器理解和处理该请求所需的所有信息。服务器不会在请求之间存储任何客户端上下文或会话状态。这一约束使 REST API 具有高度可伸缩性，因为任何服务器都可以处理任何请求。
客户端-服务器架构
客户端和服务器是分开的，API 充当它们之间的接口。这种分离关注点的做法使客户端应用和服务器端应用能够独立演化。
统一的界面
REST 要求客户端和服务器之间有一个一致、统一的接口。这是通过使用标准 HTTP 方法、用于资源标识的 URI 以及超媒体即应用状态引擎 (HATEOAS) 来实现的。
可缓存性
服务器的响应应指定为可缓存或不可缓存。当响应可缓存时，客户端或中间服务器可以为后续的相同请求重复使用该响应，这可以显著提高性能并减少服务器负载。
分层系统
连接到 REST API 的客户端通常无法判断它是直接连接到最终服务器，还是连接到沿途的中间服务器。可以在架构中引入 API 网关或负载均衡器等中间服务器，以提高可伸缩性、安全性和性能。
REST API 最佳实践
使用名词表示资源
URI 应表示资源，因此应使用名词（集合使用复数形式，某个特定项使用单数形式或 ID），而不是动词。例如，使用 /users 来表示所有用户，而不是 /getAllUsers。
正确使用 HTTP 方法
使用标准 HTTP 动词来表示操作：GET 用于检索，POST 用于创建，PUT 用于更新，DELETE 用于移除。这会创建一个可预测且一致的接口。
实现 HATEOAS（超媒体即应用状态引擎）
REST 的一个关键原则是，响应应包含指向其他相关操作或资源的链接。这样，客户端就可以动态浏览 API，而无需对 URI 模式进行硬编码。
版本控制
当您需要对 API 进行破坏性更改时，请引入新版本。最常见的做法是在 URI 中包含版本号，例如 /api/v2/users。这样，现有客户端可以继续使用旧版本，而新客户端可以使用新版本。
妥善处理错误
当请求失败时，在响应正文中提供清晰有用的错误消息，并附上适当的 HTTP 状态代码（例如 400 Bad Request、500 Internal Server Error）。这有助于客户端开发者了解问题所在。
安全性（身份验证和授权）
实施强健的身份验证（例如 OAuth 2.0、API 密钥）来验证客户端的身份，并实施完善的授权来确保客户端只能访问其有权查看的资源，从而保护您的 API。始终使用 TLS/SSL 对流量进行加密。
分页、过滤和排序
对于可能返回大量条目的端点，请实现分页功能，以便返回易于管理的数据块。此外，请提供查询参数，让客户端能够对结果进行过滤和排序，从而减少传输的数据量。
使用 REST API 的优势
简单易懂
简单易懂
REST API 使用标准 HTTP 方法和人类可读的 URI，因此开发者能够相对轻松地学习、使用和调试它们。接口的自描述特性简化了集成工作。
可伸缩性
可伸缩性
REST 的无状态特性是实现可伸缩性的关键。由于服务器不需要维护客户端会话，因此可以轻松地将请求分配到多个服务器，并且可以添加新服务器来处理更多负载，而不会增加复杂性。
灵活性
灵活性
REST 支持多种数据格式，其中 JSON 因其轻量化特性和广泛支持而最受欢迎。这种灵活性使得 REST API 可供各种客户端应用使用，包括网络浏览器、移动设备和 IoT 传感器等待。
客户端与服务器解耦
客户端与服务器解耦
REST 强制实施的客户端-服务器架构可以实现关注点的明确分离。这使开发者可以分别处理客户端前端和服务器端后端，从而加快开发周期。
与编程语言无关
与编程语言无关
由于 REST 是一种基于标准 HTTP 构建的架构风格，因此可以使用任何编程语言来实现，并且可以被任何能够发出 HTTP 请求的客户端使用。这可实现不同技术栈之间的最大互操作性。
REST API 示例
公共 API 示例
一个常见的应用场景是，移动天气应用从公共天气 API 获取特定位置的当前天气。
客户端应用向 API 端点发出 HTTP GET 请求，其中包含位置和用于身份验证的 API 密钥。
curl "https://api.weather-service.com/v1/current?location=94043&key=YOUR_API_KEY" |
curl
"https://api.weather-service.com/v1/current?location=94043&key=YOUR_API_KEY"
服务器处理请求，检索指定位置的天气数据，并返回 JSON 响应。
{ "temperature": 20, "unit": "celsius", "condition": "Clear", "humidity": 55 } |
{
"temperature": 20,
"unit": "celsius",
"condition": "Clear",
"humidity": 55
}
内部 API 示例
在微服务架构中，“产品”服务可能需要从“库存”服务获取更新后的价格，然后才能在电子商务网站上显示价格。
产品服务向库存服务的 API 端点发出内部 HTTP GET 请求，以获取特定产品 ID 的价格信息。
curl "http://inventory-service.internal/api/products/PN-5821/price" |
curl
"http://inventory-service.internal/api/products/PN-5821/price"
库存服务查找当前价格并返回一个简单的 JSON 响应。
{ "productId": "PN-5821", "price": 1299.99, "currency": "USD" } ``` |
{
"productId": "PN-5821",
"price": 1299.99,
"currency": "USD"
}
```
其他资源
- Google APIs Explorer 是一款交互式工具，可让您直接通过浏览器探索和测试各种 Google REST API
- 这篇博文提供了全面指南，介绍了设计和开发 RESTful Web API 的最佳实践
- Google Cloud Skills Boost 上的 Cloud Hero 学习路线提供动手实验，帮助您获得 API 管理方面的实战经验
