同事说:后台接口不能使用除 post/get 之外的方法,path 里不能带参数

[unco020511]

我写了接口文档,尽量按照 RESTful 风格写的,然后前端+部分后台同事说不能用 put 和 delete,还有 path 里不能带参数; 我问为啥,他说这样不规范 我该如何说服同事?

获取对应学期下评语:[get] /back/remark/{termId} 删除数据:[delete] /back/record/{recordId}

[iugo]

@SY413927 如果不是网关撑着, 从网络角度来说, 参数放在 path 里后端做起来更快. method URL, header 这些都会在 HTTP 请求接收的时候就收到完整的, 但 body 一般会以流的形式传入, 肯定是慢与 path 的.

当然, 如果后端有统一的网关, 这些都是网关的事儿, 对后端来说都一样.

[iugo]

有些事情, 的确不是优雅, 但也是有原因的.

比如提交数据的时候用 GET. 比如某某公司的日志记录.

比如获取数据的时候用 POST. 比如参数放 path query 里 URL 超长了.

[markgor]

我也覺得使用 POST/GET 比較好。
第一：常規請求就是使用 POST/GET 進行的，這兩個方式一般不會翻車。
第二：由於 PATCH/PUT/DEL 請求比較少眾，如果為了方便和通用性，還不如改為 POST/GET。
第三：WAF 一般都會攔截這些操作(當然可以手工開啟)，另外自動化滲透也會爆“疑似配置不當”，如果是網警出函，則需要書面寫說明回復。(當時有個站點由於需要跨站操作，開啟了 OPTION，但是有配置 allow，最後還是一個月收一次函，第二次收函時候直接把 OPTION 關了，域名增加多了個解釋就好了..)..

使用 PATCH/PUT/DEL 這些
優點：在於遵守 resetfull 的建議，通過接口 method 就能大概知道做什麼的了。
缺點：上面的 1、2、3.

使用 POST/GET 這些
優點：上面的 1、2、3.
缺點：不夠 resetFull 優雅，需要從接口參數才能看出大概做什麼的。

但是，現在基本的 api 都有搭配文檔的，所以我覺得已經不需要從 method 來看出他是做什麼的，畢竟就算你能從 method 看出作用，最後還不是要乖乖地看文檔？

[DelayNoMore]

是的，我的 Django 框架全是 post 和 get

[hitsmaxft]

你只要写个 api 的封装，自己定好参数， 出了问题丢给他自己查去。。有什么关系

[binux]

我拓展说一下为什么，这就是为什么在国内「 35 岁以上不要」的原因。

从这贴可以看出，35 岁程序员的经验都是什么「这么做是有原因 」，而不是「 我在 35 岁的时候把网关拦截 OPTION 的 BUG 给改了」。就这样的和 25 岁的程序员有什么区别？
10 年的经验没有用在把系统变得更好，没有把路拓宽，而是守着一条泥巴路，然后拦着后辈说别的路走不通。这样的「 35 岁以上不要」也罢。

[liuyibao]

@fkdog 👍🏻

[IamUNICODE]

以前带了个小弟，来的时候跟他说获取数据用 get，修改删除用 post,因为如果用户被禁用还是可以获取数据，但是不能增删改，结果他偏要用别的，等我反应过来的时候都上线了，结果临时改中间件，现在想来还是头疼。

[hitsmaxft]

restful， 说实话，用的地方不多。简单场景下，patch 里带参数，前后端的都麻烦， 涉及到 path + param 的参数解析合并问题。

path 可以在协议层高效处理，不用去字符串拆分 querystring，高性能网关会希望明确通过 path 区分目标服务

按我经验聊聊吧， /path 一般是用于隔离不同的目标业务
?querystring 用来提交参数， 再复杂点，涉及写入就要求 post 和 校验 session

比如你这个 /remark /record 其实都是 data query，/query?type=remark&id=123 区别不大。

但是对于 html 路径 比如访问某个人的页面 /person/id231 显得干净一些。

[gaius]

restful 不同的接口请求路径一样，做权限还得在接口上写注解

[vow]

@fkdog 这是明白人 restful api 该用的时候可以用 如果遇到复杂逻辑该不用就不用, 没必要较劲

[bnm965321]

上面有人说阿里的网关都是 GET/POST 支撑的，不知道阿里云算不算阿里的网关: https://www.alibabacloud.com/help/zh/doc-detail/31982.htm?spm=a2c63.p38356.879954.30.1ea6356aX99mJf#reference-iqc-mqv-wdb

[alphakevin]

努力让自己变得更牛，做到架构师，那时后端就不敢怼你了接口文档了！在一个低效的团队中，话语权掌握在“资历深”的人手里。当然你到了那个位置，也不会纠结用那种 method 了

[luxinfl]

个人觉得 restful 风格挺麻烦的，这主要还是看公司吧。想快速开发的一般不会这样做吧。像我们，统一使用 post，连获取数据都不用 get

[SteveAlan]

能说说 restful 可以带来什么效益吗？一直不理解

[unco020511]

@binux 有一些体会;我认为安全不通过应该是考虑安全团队去更新基础库和组件,而不是以这个理由来说 rest 不规范,实在有些牵强,可以说当前不适合,先别用;

[unco020511]

@fkdog 楼主 java 确实是小年轻,因为原先是移动端和前端,刚接手 java 业务不久;我不认为阿里的网关都是 get/post,我接入过阿里的服务

[SimonOne]

@xxdd #106 @securityCoding #110 https://www.v2ex.com/t/336226?p=1

[unco020511]

大家的每一条评论我都有认真看,感谢大家的建议.

[RJH]

获取对应学期下评语:[get] /back/remark/{termId}
这种其实有个痛点，如果系统统一搞了方法签名的话，URL 带参等于又要额外维护一套方法签名的逻辑。
如果是对外的厂商，你提供的 sdk 也需要进行支持，无形中增加了不必要的工作量。