路由设计、HTTP状态码、版本控制与完整规范
REST(Representational State Transfer)是Web API设计的事实标准。一个好的RESTful API不仅让前端开发者用起来舒服,还能降低维护成本、提高系统的可扩展性。然而,很多开发者对REST的理解停留在"用JSON返回数据"的层面,忽略了其核心设计原则。本指南将系统性地介绍RESTful API的设计规范和最佳实践。
✅ 推荐:
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 # 用单数
✅ 推荐:
GET /api/users/123/orders # 用户的订单
GET /api/orders?userId=123 # 更好的替代方案
❌ 避免:
GET /api/users/123/orders/456/items/789/details # 嵌套过深
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
| 方法 | 用途 | 幂等性 | 请求体 |
|---|---|---|---|
| GET | 获取资源 | 是 | 无 |
| POST | 创建资源 | 否 | 有 |
| PUT | 完整替换资源 | 是 | 有 |
| PATCH | 部分更新资源 | 否 | 有 |
| DELETE | 删除资源 | 是 | 无 |
# PUT - 客户端必须发送完整的资源
PUT /api/users/123
{
"name": "张三",
"email": "zhangsan@example.com",
"age": 28,
"role": "admin"
}
# PATCH - 只发送需要修改的字段
PATCH /api/users/123
{
"age": 29
}
正确使用状态码是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" }
]
}
// 方式一:URL路径版本(推荐)
GET /api/v1/users
GET /api/v2/users
// 方式二:请求头版本
GET /api/users
Accept: application/vnd.myapi.v2+json
// 方式三:查询参数版本
GET /api/users?version=2
好的API文档是团队协作的基础。推荐使用OpenAPI(Swagger)规范编写文档,配合Swagger UI提供交互式文档。自动化文档工具如Springdoc、NestJS Swagger等可以根据代码注解自动生成文档,减少维护成本。
访问 ToolSnap 获取更多开发者工具,包括JSON格式化、Base64编解码、URL编解码等实用功能。
REST的核心原则包括:资源导向(用URL标识资源)、统一接口(使用标准HTTP方法)、无状态(每个请求包含所有必要信息)、分层系统(客户端不需要知道直接连接的是终端服务器还是中间代理)。
常见方式有三种:URL路径版本(/api/v1/users)、请求头版本(Accept: application/vnd.api.v1+json)和查询参数版本(/api/users?version=1)。URL路径版本最直观,推荐大多数项目使用。
PUT用于完整替换资源(客户端发送完整的资源表示),PATCH用于部分更新(只发送需要修改的字段)。PUT是幂等的,多次执行结果相同;PATCH不一定是幂等的。