非说不多说,直接上内容
/user/{id} GET 根据用户id查询用户
/user POST 新增用户
/user PUT 修改用户
/user{id} DELETE 删除用户
如上是典型的restful 风格的url定义,在游览器开发者模式(F12)看来就是这样
| Name | Size | Time | … |
|---|---|---|---|
| 45454645 | 2.6k | 50ms | … |
| 54645456 | 2.6k | 50ms | … |
| 12345678 | 2.6k | 50ms | … |
| 45645645 | 2.6k | 50ms | … |
| 12213545 | 2.6k | 50ms | … |
| 98978976 | 2.6k | 50ms | … |
| 13545687 | 2.6k | 50ms | … |
| 13546879 | 2.6k | 50ms | … |
| 45345245 | 2.6k | 50ms | … |
| 34534535 | 2.6k | 50ms | … |
| 23443456 | 2.6k | 50ms | … |
| 45645645 | 2.6k | 50ms | … |
| 95464566 | 2.6k | 50ms | … |
| 84546566 | 2.6k | 50ms | … |
| 79784565 | 2.6k | 50ms | … |
| 56843654 | 2.6k | 50ms | … |
| 35498256 | 2.6k | 50ms | … |
| 56453783 | 2.6k | 50ms | … |
| 13548798 | 2.6k | 50ms | … |

看出什么问题没?如果全是查询接口,想定位查看接口数据,打开调试者模式,全是数字!!!
所以restful风格的接口,会增加排查问题的难度。那么就代表restful风格是垃圾?继续操作,如下:
右键表头,把path打开。

就可以看到URI全貌,那么问题就此解决?不,还没完
如果场景复杂,URI的命名空间会想当长,那么就需要把path栏调的很宽!

所以,在复杂场景,个人觉得,url的名字为 “操作 + 操作的资源”更好,比如
user/add_user # 蛇形命名
user/addUser # 驼峰命名
这样的形式,会更加易于定位!
简单场景,restful风格看起来更舒服些
欢迎各位有不同意见、并评论~
本文讨论了RESTful风格接口在实际应用中的问题,如查询接口过多导致问题排查困难,以及命名空间过长的问题。作者提倡在复杂场景中使用明确的操作和资源标识,如蛇形命名或驼峰命名,以提高问题定位效率。
21万+






