Day 9|RESTful API 设计 & 错误处理
·
第一部分:什么是 RESTful API?
REST = Representational State Transfer
它不是框架,而是一种 接口设计规范思想。
核心理念:
👉 用 URL 表示资源
👉 用 HTTP 方法表示操作
当你遵守 REST:
-
浏览器
-
代理服务器
-
CDN
-
缓存系统
都可以根据 HTTP 方法自动优化。
比如:
-
GET 可以缓存
-
DELETE 不缓存
-
PUT 是幂等的
如果你把动词写在 URL 里:
这些基础设施全部失效。
❌ 非 RESTful 写法(新手常见)
GET /getUsers
POST /createUser
POST /deleteUser
这是“动词式接口”
为什么 RESTful 里 URL 不能写动词?
一句话答案:
👉 因为 URL 只用来表示“资源”,而“做什么操作”应该由 HTTP 方法决定。
✅ RESTful 写法(专业)
GET /users 获取用户列表
GET /users/1 获取单个用户
POST /users 创建用户
PUT /users/1 修改用户
DELETE /users/1 删除用户
👉 URL 只表示“资源”
👉 操作由 HTTP 方法决定
第二部分:HTTP 方法语义
| 方法 | 含义 | 是否幂等 |
|---|---|---|
| GET | 获取数据 | ✅ 是 |
| POST | 创建数据 | ❌ 否 |
| PUT | 全量更新 | ✅ 是 |
| PATCH | 局部更新 | ❌ |
| DELETE | 删除 | ✅ |
幂等 = 多次请求结果一样
例如:DELETE /users/1
删 10 次,结果一样 —— 用户没了。
第三部分:HTTP 状态码必须会
这是今天重点。
常用成功状态码
| 状态码 | 含义 |
|---|---|
| 200 | 成功 |
| 201 | 创建成功 |
| 204 | 删除成功(无内容) |
常用错误状态码
| 状态码 | 含义 |
|---|---|
| 400 | 参数错误 |
| 401 | 未登录 |
| 403 | 无权限 |
| 404 | 找不到资源 |
| 500 | 服务器错误 |
❌ 新手错误写法
res.send({
code: 200,
message: "删除失败"
})
HTTP 层是 200,但业务失败 ❌
✅ 正确写法
res.status(400).json({
message: "参数错误"
})
第四部分:Express 错误处理机制(核心)
Express 有专门的错误中间件。
标准错误中间件写法
app.use((err, req, res, next) => {
console.error(err)
res.status(err.status || 500).json({
message: err.message || '服务器内部错误'
})
})
⚠ 注意:必须 4 个参数(err, req, res, next)
否则不是错误中间件。
在路由中如何触发错误?
app.get('/users/:id', (req, res, next) => {
const id = req.params.id
if (!id) {
const err = new Error('ID 必填')
err.status = 400
return next(err)
}
res.send('ok')
})
好的 我们说明下 为什么这里return next(err) 不是四个参数了
return next(err) 是在触发错误流程。
因为:
👉 触发错误 ≠ 处理错误
路由的职责是:发现错误 → 调用 next(err)
错误中间件的职责是:接收 err → 统一处理
| 场景 | 参数 |
|---|---|
| 普通中间件 | (req, res, next) |
| 错误中间件 | (err, req, res, next) |
| 触发错误 | next(err) |
进阶一点:统一错误封装(推荐写法)
class AppError extends Error {
constructor(message, statusCode) {
super(message)
this.status = statusCode
}
}
使用:
return next(new AppError('用户不存在', 404))
更多推荐
所有评论(0)