RESTful 架构详解
RESTful（Representational State Transfer，表述性状态转移）是一种软件架构风格，主要用于设计网络应用程序的 API（应用程序接口）。它基于 HTTP 协议，强调资源的表述和状态转移，适用于分布式系统和 Web 服务开发。
应用其实也简单,我觉得吧,就是和注解结合,做成一种统一的代码风格,看起来比较整齐,闲话稍许,让我们回到正题.
1. RESTful 的核心概念
(1) 资源（Resource）
-
RESTful 的核心是资源，每个资源都有一个唯一的标识符（URI）。
-
例如：
/users表示用户集合/users/1表示 ID 为 1 的用户
(2) 表述（Representation）
- 资源可以有多种表述形式（如 JSON、XML、HTML）。
- 客户端通过 HTTP 请求获取资源的某种表述（如
Accept: application/json）。
(3) 状态转移（State Transfer）
-
客户端通过 HTTP 方法（GET、POST、PUT、DELETE）操作资源，改变其状态。
-
例如：
GET /users获取用户列表POST /users创建新用户PUT /users/1更新用户 1DELETE /users/1删除用户 1
(4) 无状态（Stateless）
- 服务器不存储客户端会话信息，每次请求必须包含所有必要信息（如 Token、Session ID）。
- 优点：提高可扩展性，降低服务器负担。
2. RESTful 的设计原则
(1) 统一接口（Uniform Interface）
- 使用标准的 HTTP 方法（GET、POST、PUT、DELETE）操作资源。
- 资源通过 URI 唯一标识。
- 使用 HTTP 状态码表示操作结果（如
200 OK、404 Not Found）。
(2) 资源导向（Resource-Oriented）
-
所有操作围绕资源进行，URI 应清晰表达资源层级。
-
例如：
/users（用户集合）/users/1/orders（用户 1 的订单）
(3) 无状态通信（Stateless Communication）
-
服务器不保存客户端状态，每次请求独立处理。
-
例如：
- 使用 JWT（JSON Web Token）进行身份验证，而不是 Session。
(4) 可缓存（Cacheable）
- 使用 HTTP 缓存机制（如
Cache-Control、ETag）提高性能。
(5) 分层系统（Layered System）
- 客户端无需知道服务器架构细节（如负载均衡、CDN）。
(6) 按需代码（Code-On-Demand，可选）
- 服务器可以返回可执行代码（如 JavaScript），但这不是必须的。
3. RESTful API 设计规范
(1) URI 设计
-
使用名词，而不是动词（资源导向）：
- ✅
/users（正确） - ❌
/getUsers（错误）
- ✅
-
使用小写字母和连字符（
-） ：- ✅
/user-profiles - ❌
/UserProfiles
- ✅
-
避免文件扩展名：
- ✅
/users/1 - ❌
/users/1.json
- ✅
-
层级关系用
/表示：/users/1/orders（用户 1 的订单）
(2) HTTP 方法使用
| 方法 | 用途 | 幂等性 | 安全性 |
|---|---|---|---|
GET | 获取资源 | ✅ 是 | ✅ 是 |
POST | 创建资源 | ❌ 否 | ❌ 否 |
PUT | 更新资源（全量替换） | ✅ 是 | ❌ 否 |
PATCH | 更新资源（部分修改） | ❌ 否 | ❌ 否 |
DELETE | 删除资源 | ✅ 是 | ❌ 否 |
(3) HTTP 状态码
| 状态码 | 含义 | 适用场景 |
|---|---|---|
200 OK | 请求成功 | GET/PUT/PATCH/DELETE 成功 |
201 Created | 资源创建成功 | POST 成功 |
204 No Content | 无返回内容 | DELETE 成功 |
400 Bad Request | 请求错误 | 参数校验失败 |
401 Unauthorized | 未授权 | 未登录 |
403 Forbidden | 禁止访问 | 权限不足 |
404 Not Found | 资源不存在 | URI 错误 |
500 Internal Server Error | 服务器错误 | 代码异常 |
(4) 数据格式
-
请求/响应通常使用 JSON：
jsonCopy Code { "id": 1, "name": "张三", "email": "zhangsan@example.com" } -
支持
Content-Type和Accept头：Content-Type: application/json（请求体格式）Accept: application/json（期望的响应格式）
4. RESTful vs. SOAP vs. GraphQL
| 特性 | RESTful | SOAP | GraphQL |
|---|---|---|---|
| 协议 | HTTP | HTTP/SMTP | HTTP |
| 数据格式 | JSON/XML | XML | JSON |
| 查询灵活性 | 固定端点 | 固定端点 | 动态查询 |
| 性能 | 较高（可缓存） | 较低（XML 冗长） | 高（按需查询） |
| 适用场景 | CRUD 操作 | 企业级 API | 复杂数据查询 |
5. 实际示例（Spring Boot RESTful API）
javaCopy Code
@RestController
@RequestMapping("/api/users")
public class UserController {
@GetMapping
public List<User> getAllUsers() {
return userService.findAll();
}
@GetMapping("/{id}")
public User getUserById(@PathVariable Long id) {
return userService.findById(id);
}
@PostMapping
@ResponseStatus(HttpStatus.CREATED)
public User createUser(@RequestBody User user) {
return userService.save(user);
}
@PutMapping("/{id}")
public User updateUser(@PathVariable Long id, @RequestBody User user) {
return userService.update(id, user);
}
@DeleteMapping("/{id}")
@ResponseStatus(HttpStatus.NO_CONTENT)
public void deleteUser(@PathVariable Long id) {
userService.delete(id);
}
}
6. 总结
✅ RESTful 的优点：
- 简单、易理解、符合 HTTP 标准
- 可扩展性强（无状态、可缓存）
- 适用于 Web、移动端、微服务架构
❌ RESTful 的缺点：
- 不适合实时通信（如 WebSocket）
- 复杂查询可能需多次请求（GraphQL 更适合）
RESTful 是目前最流行的 API 设计风格，适用于大多数 Web 服务开发场景。
