RESTful API设计最佳实践指南

路由设计、HTTP状态码、版本控制与完整规范

📅 2026年4月6日 · 阅读约10分钟 · API设计REST后端开发

REST(Representational State Transfer)是Web API设计的事实标准。一个好的RESTful API不仅让前端开发者用起来舒服,还能降低维护成本、提高系统的可扩展性。然而,很多开发者对REST的理解停留在"用JSON返回数据"的层面,忽略了其核心设计原则。本指南将系统性地介绍RESTful API的设计规范和最佳实践。

一、REST核心原则

二、URL路由设计

2.1 使用名词复数

✅ 推荐:
GET    /api/users          # 获取用户列表
GET    /api/users/123      # 获取单个用户
POST   /api/users          # 创建用户
PUT    /api/users/123      # 替换用户
DELETE /api/users/123      # 删除用户

❌ 避免:
GET    /api/getUsers
POST   /api/createUser
GET    /api/user/123       # 用单数

2.2 资源嵌套不超过两层

✅ 推荐:
GET /api/users/123/orders          # 用户的订单
GET /api/orders?userId=123         # 更好的替代方案

❌ 避免:
GET /api/users/123/orders/456/items/789/details  # 嵌套过深

2.3 使用查询参数处理过滤、排序和分页

GET /api/users?role=admin&status=active     # 过滤
GET /api/users?sort=-createdAt,name         # 排序(-表示降序)
GET /api/users?page=2&limit=20              # 分页
GET /api/users?fields=id,name,email         # 字段选择
GET /api/users?search=张三                  # 搜索

# 组合使用
GET /api/products?category=electronics&minPrice=100&maxPrice=500&sort=-price&page=1&limit=10

三、HTTP方法正确使用

方法用途幂等性请求体
GET获取资源
POST创建资源
PUT完整替换资源
PATCH部分更新资源
DELETE删除资源

PUT vs PATCH

# PUT - 客户端必须发送完整的资源
PUT /api/users/123
{
  "name": "张三",
  "email": "zhangsan@example.com",
  "age": 28,
  "role": "admin"
}

# PATCH - 只发送需要修改的字段
PATCH /api/users/123
{
  "age": 29
}

四、HTTP状态码

正确使用状态码是RESTful API的基本功。不要所有响应都返回200。

状态码含义使用场景
200 OK成功GET、PUT、PATCH、DELETE成功
201 Created已创建POST创建资源成功
204 No Content无内容DELETE成功,无需返回body
400 Bad Request请求错误参数验证失败、格式错误
401 Unauthorized未认证缺少或无效的认证信息
403 Forbidden无权限已认证但无权访问该资源
404 Not Found未找到资源不存在
409 Conflict冲突资源状态冲突(如邮箱已注册)
422 Unprocessable Entity验证失败请求格式正确但语义错误
429 Too Many Requests请求过多触发限流
500 Internal Server Error服务器错误未预期的服务器异常

五、统一响应格式

// 成功响应
{
  "code": 200,
  "message": "success",
  "data": {
    "id": 123,
    "name": "张三",
    "email": "zhangsan@example.com"
  }
}

// 分页响应
{
  "code": 200,
  "data": {
    "items": [...],
    "pagination": {
      "page": 2,
      "limit": 20,
      "total": 156,
      "totalPages": 8
    }
  }
}

// 错误响应
{
  "code": 400,
  "message": "参数验证失败",
  "errors": [
    { "field": "email", "message": "邮箱格式不正确" },
    { "field": "age", "message": "年龄必须大于0" }
  ]
}

六、API版本控制

// 方式一:URL路径版本(推荐)
GET /api/v1/users
GET /api/v2/users

// 方式二:请求头版本
GET /api/users
Accept: application/vnd.myapi.v2+json

// 方式三:查询参数版本
GET /api/users?version=2
💡 推荐:URL路径版本最直观,便于调试和文档管理,适合大多数项目。API版本号应使用主版本号(v1、v2),向后兼容的小改动不需要升版本。

七、安全最佳实践

八、API文档

好的API文档是团队协作的基础。推荐使用OpenAPI(Swagger)规范编写文档,配合Swagger UI提供交互式文档。自动化文档工具如Springdoc、NestJS Swagger等可以根据代码注解自动生成文档,减少维护成本。

🛠️ 在线API工具

访问 ToolSnap 获取更多开发者工具,包括JSON格式化、Base64编解码、URL编解码等实用功能。

常见问题(FAQ)

RESTful API的核心原则是什么?

REST的核心原则包括:资源导向(用URL标识资源)、统一接口(使用标准HTTP方法)、无状态(每个请求包含所有必要信息)、分层系统(客户端不需要知道直接连接的是终端服务器还是中间代理)。

API版本控制有哪些方式?

常见方式有三种:URL路径版本(/api/v1/users)、请求头版本(Accept: application/vnd.api.v1+json)和查询参数版本(/api/users?version=1)。URL路径版本最直观,推荐大多数项目使用。

什么时候用PUT,什么时候用PATCH?

PUT用于完整替换资源(客户端发送完整的资源表示),PATCH用于部分更新(只发送需要修改的字段)。PUT是幂等的,多次执行结果相同;PATCH不一定是幂等的。