RESTful
约 463 字大约 2 分钟
2025-12-08
RESTful 规范 是一组用于设计网络应用接口的架构风格和约束原则,其核心目标是利用 HTTP 协议的语义来表达资源的操作。 它不是一个正式标准,而是一种广泛接受的约定。
设计原则包括以下几点:
1. 资源导向与 URI 设计
- 每个资源有唯一的 URI。
- URI 应为名词,不用动词。
✅ 正确:/users、/users/123
❌ 错误:/getUsers、/deleteUser - URL 体现资源从属关系。
GET:/users/123/orders,表示获取 用户 123 的所有订单
2. HTTP 方法表达操作语义
| HTTP 方法 | 语义 | 幂等 | 安全(不修改资源) |
|---|---|---|---|
| GET | 获取资源 | 是 | 是 |
| POST | 创建资源 或 执行非幂等操作 | 否 | 否 |
| PUT | 全量更新资源 | 是 | 否 |
| PATCH | 部分更新资源 | 否 | 否 |
| DELETE | 删除资源 | 是 | 否 |
3. 统一接口
- 资源识别(URI)
- 通过表述操作资源(如 JSON/XML)
- 自描述消息(含 Content-Type、状态码等)
4. 使用标准 HTTP 状态码
200 OK:成功获取或操作201 Created:资源创建成功(响应中应含Location头)204 No Content:操作成功但无返回体(如 DELETE 成功)400 Bad Request:客户端请求错误401 Unauthorized:未认证403 Forbidden:无权限404 Not Found:资源不存在409 Conflict:资源冲突(如重复创建)500 Internal Server Error:服务器内部错误
6. 统一响应格式
- 资源通常为 JSON,信息应该包含状态码,错误信息等。
- RESTful 没有强制规定响应格式,但响应体应结构清晰。
{ "code": 200, // 状态码 "message(msg)": "success", // 状态信息 "data": { // 实际业务数据 } }
RESTful 规范的本质是利用 HTTP 协议本身的能力(方法、状态码、URI),以资源为中心,设计出可读、可预测、易于维护和扩展的 API。