REST API 设计和命名约定指南
有效地设计RESTful API对于创建可扩展、可维护且易于使用的系统至关重要。虽然存在某些标准，但许多标准并不是严格的规则，而是指导 API 设计的最佳实践。一种广泛使用的 API 架构模式是 MVC（模型-视图-控制器），但它本身并不能解决 API 设计的更精细方面，例如命名和结构。在本文中，我们将逐步介绍构建 REST API 的基本准则。
- 命名约定和面向资源的设计 API 通常是围绕资源定义的，资源代表系统中的实体，例如“用户”、“产品”或“订单”。资源可以是单个项目或集合，API 应提供直观且清晰的方式与这些资源进行交互。
主要原则：
面向资源：围绕资源而不是操作设计 API。资源应该被视为名词，而不是动词。例如：
/users 用于访问用户集合。
/users/{userId} 用于访问特定用户。
一致性：API 应该直观。如果用户可以从 /users 获取资源列表，他们应该期望能够通过添加标识符来获取单个资源：/users/{userId}.
集合与单一资源：
资源集合由复数名词表示：/users、/products。
单个资源通过附加该资源的唯一标识符来表示：/users/{userId}、/products/{productId}.
- HTTP 方法定义操作，而不是 URI 正在执行的操作（无论是检索数据、创建新条目还是更新现有数据）不应嵌入 URI 中。相反，HTTP 方法决定操作。
常见的 HTTP 方法及其用例：
GET：从服务器检索数据。
示例：GET /products 返回所有产品的列表。
示例： GET /users/{userId} 检索具有指定 userId 的用户。
POST：在服务器上创建新资源。
示例：POST /users 创建一个新用户。
PUT：用新数据替换现有资源（完全更新）。
示例：PUT /users/{userId} 将用户的数据完全替换为新数据。
PATCH：部分更新现有资源（部分更新）。
示例：PATCH /users/{userId} 仅更新指定的属性，例如电话号码。
DELETE：删除资源。
示例：DELETE /users/{userId} 删除指定 userId 的用户。
- REST 中的无状态 REST API 应该是无状态的，这意味着每个 API 调用都必须包含服务器处理请求所需的所有信息。这确保每个请求都是自给自足的，并且不依赖于之前的请求。
示例：当发出 GET 请求来获取用户详细信息时，该请求必须包含所需的授权令牌，即使先前的请求已经对用户进行了身份验证。这在分布式系统中至关重要，因为不同的请求可能会到达不同的服务器。
- 避免特定于服务器的数据存储 任何单个 API 请求都不应依赖于在特定服务器上存储临时数据。在分布式系统中，传入请求可能会路由到任何服务器，因此无论哪个服务器处理请求，都应该实现相同的结果。这就是为什么会话状态不应存储在单独的服务器上。
解决方案：对于会话管理，请使用集中式或分布式存储系统（例如 Redis）或无状态身份验证机制（例如 JWT（JSON Web Token））。
- 资源与数据库表 您的 API 设计不应在数据库表和 API 端点之间具有一对一的映射。 API 应公开逻辑上有意义的资源，这些资源可以组合来自多个表或源的数据。
示例：
GET /orders/{orderId} 可能会检索订单详细信息，结合订单、order_items 和客户表中的信息。
- 数据类型的灵活性 REST API 不受数据库的数据类型或表结构的限制。您可以以最适合您的 API 消费者的方式构建您的响应。虽然 JSON 是最常用的格式，但如果需要，您可以自由返回 XML 或 CSV 等其他格式的数据。
示例：GET /reports/{reportId} 端点可能会根据请求中的查询参数或标头返回各种格式（JSON、CSV、PDF）的报告。
API 结构示例
为了将所有这些原则联系在一起，这里有一个遵循这些最佳实践的 API 结构示例：
GET /products：检索所有产品。
GET /products/{productId}：检索特定产品的详细信息。
POST /products：创建新产品。
PUT /products/{productId}：将产品替换为productId。
PATCH /products/{productId}：部分更新产品。
DELETE /products/{productId}：删除产品。
在这种结构中，资源被明确定义，HTTP 方法指定要采取的操作，确保 API 干净直观。
**结论
**设计 RESTful API 不仅仅涉及创建路由和处理 HTTP 方法。通过关注资源、利用 HTTP 方法进行操作并遵守无状态性，您可以创建直观、可维护和可扩展的 API。请记住，API 应该灵活且独立于特定的数据库结构，以便随着系统的发展提供更多的适应性。
遵循这些约定可确保您的 API 设计既高效又用户友好，从而最终增强 API 开发人员和消费者的体验。
以上就是REST API 设计和命名约定指南的详细内容，更多请关注其它相关文章！