前后端 api 接口 url 格式问题讨论

[pandazhong123]

公司的前后端 api 接口统一用 post,对于添加删除用户，是用 /user/add /user/delete 比较好，还是用 /add/user /delete/user 比较好？

[simo]

团队共识就可，可以参考通用做法，有人发文章了。
如果多了解一下其他协议的业务通信设计，理解不同，自由度会更高

[zhch602]

现在又有人在用 RESTful 么

[x86]

说句难听的，培训机构都没这么水教这种写法
```
/add/user
/delete/user
```

[nothingistrue]

@theqiang #28 按下 SHIFT+ENTER 换行，结果直接提交回复了，下面一楼才是完整回复。但是好多人好像只看到我这个半回复，没看下面的完整回复。

@hidemyself #29
DELETE /user?phone=xxx 跟「根据用户手机号查询用户列表」，是一样的套路。

@george2077 #44 /user/add /user/delete 并不符合 RESTful API 的设计原则。RESTful API 的基准原则就是，URL 仅表示资源路径故只能是名词或者等效于名词的东西，GET/POST/PUT/PATCH/DELETE 这几个 method 才能表示动作。所以只能是 POST /user ，DELETE/user 。（单复数我忘了，好像应该是复数形式。）如果你用/user/add ，最经典的问题就是 @Pastsong #27 提到的 /user/{id}冲突。但他的 /user:add 这样也不对。

严格 RESTful API 有一个经典缺点，就是 GET/POST/PUT/PATCH/DELETE 动作不够，无法表示其他方法。当你采用领域模型来设计接口的时候，这个确定会更突出，因为领域模型在增删该查之外会有大量的其他行为方法。这个在后面单独说。

@lambdaq #50 根据 ID 批量删除：DELETE /user?id=xx,xx,xx 。根据条件（批量）删除：DELETE /user?condition=xxx

[liuzhaowei55]

post /module/action
离那个所谓的 restful 远一点就对了

[lambdaq]

@nothingistrue 那为啥不直接 POST /user/delete 。。。。

[codehz]

快进到直接 graphql ，在 body 里 mutation { deleteUser(id: "xxx") { result } }

[nothingistrue]

关于 RESTful API 如何表示领域行为方法，这个我也是抄别人的，就直接贴链接了。
原文（也是翻译老外的）链接： https://mp.weixin.qq.com/s/251ql2WhDi-InUgVtIQ6_Q
我看的是转发： https://blog.didispace.com/use-ddd-design-rest-api/
请注意，这也是违反 RESTful 的，需要有全局约定才能这么做。他并不存在冲突，因为 PUT /resources/{id}/action 是专有的 URI （原本的 PUT 因为是修改指定资源，其 URL 形式必定是 PUT /resources-level1/{id}/resources-level2/{id}的形式。）

关于 REST 的参考： https://restfulapi.net/resource-naming/

关于单复数的部分，需要纠正，REST 接口，资源必须定义成复数，因为单数名词有特殊含义，他是定义可选的前置分组的。当然，这是个认为约定，不是强制规定。如果约定好，全部单数也不是问题。

再纠正一下 14 楼的回复。「如果是一般动作，那就是 POST /user/{id}/%动词%，比如 POST /user/{id}/disable 。」是错误的。应改为「如果是一般动作，那就是 PUT /users/{id}/%动词%，比如 PUT /users/{id}/disable 。」因为这个动作，是对当前资源的修改，不是新增资源。

[tairan2006]

全 post 的话，动词放最后，get/list/create/update/delete

其实和 Rest 没啥区别……

[zorui]

@hidemyself DELETE /user/phonenumber/{phonenumber} ? 或者参数放进 body 中

[nothingistrue]

@lambdaq #65 会跟新增 「 user 」 的 「 delete 」 冲突。

[sgiyy]

op 工作经验超过一年吗？

[pandazhong123]

@x86 哈哈，从 C++转到 web 开发的，对这 Web 不熟。
其实我还有其他疑问，在 url 中，是 bookDetail 比较好，还是 book_detail,还是 book-detail?

[lambdaq]

@pandazhong123 你扮演一个需要分析服务器访问日志，随时准备骂娘的角色， 就知道哪种 URL 好了。

[blackkkk]

一般是/分组 or 模块/对应操作--》/user/add or /user/addUser ，冗余在这里并不是什么问题，更便于理解，因为在 user 下可能不止 user 一个操作，比如用户和其他的映射等信息。

[ElvY]

毫无疑问前者。和命名相同逻辑，后者绝壁要挨打。

[nothingistrue]

@pandazhong123 #72 如果是面向传统前端的标准 URL ，或者 RESTful ，或者是公开接口，那么应当是 book-detail 。URL 在部分场景（比如 Windows IIS 当服务器），是不区分大小写的。下划线则是在部分字体或者 UI 下，容易看不见。如果仅面向当前项目的前端，那就看团队习惯，对于全 Java 系开发来说，bookDetail 更舒适。

[kkk9]

随便后端怎么写，随便前端怎么 mock ，最后都是要在网关那边 rewrite 的，这种东西团队内部 ok 就行了。

/user/add /模块/动作

[jeesk]

用 grpc web ，没有争论。 有这时间，不如多优化一下代码。

[flyqie]

@kkk9 #78

那/add/user 这种情况就变成网关要骂娘了。。