这是一个创建于 2120 天前的主题，其中的信息可能已经有所发展或是发生改变。
我写了接口文档,尽量按照 RESTful 风格写的,然后前端+部分后台同事说不能用 put 和 delete,还有 path 里不能带参数; 我问为啥,他说这样不规范 我该如何说服同事?
获取对应学期下评语:[get] /back/remark/{termId} 删除数据:[delete] /back/record/{recordId}
 | 1 killergun 2020-01-02 16:44:45 +08:00 听老大的 |
 | 2 luckyrayyy 2020-01-02 16:45:46 +08:00 少数服从多数，费这个劲干啥。 |
 | 3 jowan 2020-01-02 16:45:47 +08:00 并不一定非要 REST 虽然我司用的是 :)狗头 前端抱怨大概是因为非 200 状态 比如 422 419 404 要捕捉异常处理 哈哈 |
 | 4 unco020511 OP 地址:某二线不大不小的厂 |
 | 5 lazyfighter 2020-01-02 16:47:31 +08:00  4 老子就这么写，爱用不用 |
 | 6 learnshare 2020-01-02 16:48:21 +08:00 六字送上，该忍就忍了，不专业才是正常的 |
 | 7 Cyron 2020-01-02 16:48:35 +08:00 谁说了算听谁的 |
 | 8 Leonard 2020-01-02 16:49:22 +08:00 我还见过后台全用 post 的，get 都不用 |
 | 9 ysyk 2020-01-02 16:49:23 +08:00 很正常，我们这边，前端说如果只用 post 是最好的 |
 | 10 lihongjie0209 2020-01-02 16:49:57 +08:00 没什么问题, 统一就好 |
 | 11 MatthewHan 2020-01-02 16:50:07 +08:00 1 拿阿里、百度等等的一些接口文档给他们看 |
 | 13 est 2020-01-02 16:52:30 +08:00 10 path 里不带参数 一时爽。。 nginx 日志分析火葬场。。。。 |
 | 14 marcong95 2020-01-02 16:53:20 +08:00 11 那你就直接给它来个 POST /api {"method": "get", "type": "remark", "termId": "{termId}"} POST /api {"method": "delete", "type": "record", "id": "{recordId}"} |
| 15 unco020511 OP 怎么写其实无所谓,但是说不规范我就不乐意了,且一副你不懂的表情 |
 | 16 yidinghe 2020-01-02 16:54:03 +08:00 但是 GET 里面传 BODY 也不合适 |
| 17 unco020511 OP @marcong95 楼主原来做移动端的时候还真见过这种,全部都是一个 url,然后参数 method 来区分具体业务 |
 | 18 a719114136 2020-01-02 16:55:59 +08:00 就一个规范，用什么都行。 之前有规范了就按照之前的。 选择规范的标准就是简单，说实话我也不喜欢 RESTful 那套，直接 post/get 就够用了 ，弄一堆 method 那么复杂。 另外 path 里带参数，这种 url 确实便于理解，我以前也挺喜欢这种风格的。但对后端来说，有的框架不能匹配这种 url ；对于前端来说不利于代码结构化。所以现在也放弃了 path 里带参数 |
| 19 unco020511 OP @yidinghe get 里传 body?咋传 |
 | 20 gwybiaim 2020-01-02 16:56:33 +08:00 REST 很重要的一条是面向资源，你可以按照常见的 rest 风格来，也可以设计自己的 rest 规范 |
| 21 lihongjie0209 2020-01-02 16:58:10 +08:00 @unco020511 #19 传不了, 只能用 query string http://xxx.com/api?a=1&b=2 其中 /api 是 path ?a=1&b=2 是 query string |
| 22 unco020511 OP @a719114136 全部用 post/get 我能理解,但是 path 不能带参数就有点奇怪; path 可以理解为资源定位,那 id 放在 path 里获取资源不应该更合理吗; 还有前端框架不支持也有点牵强,我原先做移动端+web,都是支持的,且新框架一般都支持的很好,比如 android 的 retrofit |
 | 23 MaPeiren 2020-01-02 17:00:25 +08:00 可以不这么做，但是不能说你不懂阿，这真的上头 |
| 24 unco020511 OP @mcfog 搜了一下发现了新天地,哈哈 |
| 25 marcong95 2020-01-02 17:05:56 +08:00 @unco020511 #17 十分经典的用来杠“反 RESTful”群体的例子了 |
 | 26 ic2y 2020-01-02 17:07:27 +08:00 9 @unco020511 如果是一个大厂，只用 GET 和 POST 还是比较靠谱的。 用 RESTful 风格 可能会有不少潜在麻烦。可能的问题有： 1.监控问题：因为监控 URL 请求的时候，需要进行 URL 聚合统计操作，如果用 RESTful 风格 非常难以提取 URL 的模型进行聚合（因为有人用 python，有人用 java，还有不同的应用框架，非常难以在 client 端进行 url 模式提取。而在 server 端模式提取要求的性能又很高。还不如直接用 get 和 post ）。 2.配套的日志采集系统：RESTful 风格 在独立上下文的日志引擎里，很难用 URL 进行模式提取。 3.配套的其他系统的问题： 统一 API 网关接入（如果是自研的，需要完整支持 restful 风格）。自动化测试系统（如果自研，也要兼容）。代码审计和代码覆盖平台 等等。 如果你用了 RESTful 风格，那么需要整个 开发运维链路上的每个环节，都要支持完整的操作。但是实际上，很多系统只是支持简单的 GET 和 POST 协议。 你不得不推动 每个团队来支持你的需求，这个等待 是很麻烦的。 |
| 27 a719114136 2020-01-02 17:07:50 +08:00 @unco020511 看错了吧，我说的是后端。 比如： * /user/ {user_id} /update * /user/ {user_id} /delete 这种类型的 url，有的框架是不支持的 |
 | 28 passerbytiny 2020-01-02 17:07:52 +08:00 不需要说服。若接口定义、实现、权责人全在你，你只管照自己走，爱用不用。若定义、实现在你但权责人不是你，准备跑路。 当然有几点要注意： 一，RESTful 是一种编码风格而不是工具，只存在用不用，不存在尽量用，若你不能让所有接口都遵循 RESTful，那就不要用。 二，RESTful 与 HTTP 相互适应，但与 HTML 并不相互适应，APP、好的前端框架能够很容易的适配 RESTful 接口，但一般的前端框架以及不用框架的 Web 开发，是只认 get、post 不认其他请求的（严格的说，底层技术是支持其他请求的，但是框架设计思想上不支持）。 三，如果接口是 RESTful，那么底层既是不是领域驱动设计，也要对此有所了解，否则你在 URI 命名上绝对会遇到矛盾。 |
| 29 unco020511 OP @a719114136 27 不好意思看错了.可能后端部分框架确实不支持吧 |
| 30 unco020511 OP @ic2y 26 这样说挺有道理,原先我没有想到这些 |
 | 31 Raymon111111 2020-01-02 17:13:10 +08:00 习惯跟随团队 |
| 32 Raymon111111 2020-01-02 17:14:20 +08:00 如果你希望说服团队 那应该能列举这么干的坏处和按照你这么干带来的好处 一句规范打发大家毫无说服力 |
 | 33 opengps 2020-01-02 17:14:38 +08:00 这么做很好，很多人不知道 put，delete。不瞒你说我工作 8 年了也没写过表单的 put，delete 方法 |
 | 34 artikle 2020-01-02 17:15:09 +08:00 @unco020511 Path 带参数 有想过接口日志统计怎么处理吗 |
| 35 Raymon111111 2020-01-02 17:15:36 +08:00 你可以从 研发效率, 出错概率, 代码易读性, debug 难度, 测试覆盖 等等角度阐述你的观点 (带来收益的事情才去做 |
| 36 passerbytiny 2020-01-02 17:16:16 +08:00 @ic2y #24 你说了那么多问题，总结起来就一句话：改起来好麻烦。如果一个大厂把这些当问题，那么这大厂要么是假的，要么“老且不能饭”。 |
 | 37 gpg 2020-01-02 17:16:46 +08:00 他这样要求说实话没毛病 |
 | 38 szq8014 2020-01-02 17:17:08 +08:00 我猜后台是 php |
| 39 szq8014 2020-01-02 17:17:56 +08:00 emmm 竟然是 java 版块。。springMVC 天然支持 restful 为啥他们不会用…… |
 | 40 randyo 2020-01-02 17:24:32 +08:00 via Android 反正只用 post 前端没意见，反正都是后端处理数据 |
 | 41 crs0910 2020-01-02 17:27:36 +08:00 |
 | 42 evlos 2020-01-02 17:31:53 +08:00 你同事说这样不规范，就显得他很弱智了 |
| 43 ic2y 2020-01-02 17:34:51 +08:00 2 @passerbytiny 我回复了这么多，不是说不能实现。企业都是讲“成本”的，不是为了支持黑科技或者新特性。 成本：不光是 开发人员的开发成本和接入成本、还有服务器（ client 和 server ）的内存消耗和 CPU 消耗。 如果支持 RESTful 风格 很容易支持的话，早就全支持了。 业务方不允许你的采集程序占用额外的内存和 CPU，自己部署的中间件平台为了额外的模式提取需要付出性能代价 而加机器。这些个都是成本制约。 如果 RESTful 风格 在没有上下文的前提下，很容易像 POST 一样提取模式，无其他明显成本消耗，就不会这么不建议了。 api?k1=v1&k2=v2 (没有上下文，各个系统能快速解析) 与 api/k1/v1/k2/v2 或者 /mock/a/k1/v2 （没有上下文，面对海量的各种地址的 URL 请求，需要付出额外的资源进行解析） |
 | 44 zhaohua 2020-01-02 17:36:49 +08:00 @szq8014 后台 php 的话就全部都是 get 了，我个人觉得只使用 get post 的简易 restful api 挺好的 |
 | 45 14v45mJPBYJW8dT7 2020-01-02 17:36:56 +08:00 有人把 http 当做传输协议，自己在 body 中定义业务 总之，能正常使用就可以了 |
 | 46 chenliangngng 2020-01-02 17:43:31 +08:00 via Android 站在前端的角度，delete 永远都不应该用，put 有风险应该在安全性没什么问题的时候才能考虑使用 |
| 47 lihongjie0209 2020-01-02 17:45:57 +08:00 @crs0910 #41 https://stackoverflow.com/questions/978061/http-get-with-request-body 自己去翻协议标准去, 没有任何地方定义了 Get 可以使用 Body 至于说框架 /标准库支持, 那是实现方的具体实现, 没有任何实际意义. 等你部署上线的时候, 你的服务器支持, 但是负载均衡不支持, 客户端类库不支持, 那么你这个还叫 http 服务器?? |
 | 48 IGJacklove 2020-01-02 17:49:07 +08:00 这个写之前不先问一下老大的吗。。。 |
 | 49 IMCA1024 2020-01-02 17:53:05 +08:00 那就 GET ,POST 吧 虽然我也赞同用 HTTP 动词描述操作 但有时候没办法 可能有时候运维那一层就把你的 PUT PATCH DELETE 给干掉。） |
 | 50 Infernalzero 2020-01-02 17:53:40 +08:00 作为规范没啥问题，做工程就是这样，不能太学院派，规范是人定的，可以根据实际需求变更。 不准用 PathVariable 最直接的原因就是访问量上去后影响匹配性能 |
 | 51 676529483 2020-01-02 17:54:19 +08:00 反正这点我也早就服气了，restful 接口并不能带来实质的改变，本质是前端的配合、公司的包袱，反正区别也不大。状态码使用{"code": 200}同理 |
 | 52 zachlhb 2020-01-02 18:00:22 +08:00 via Android 很正常，很多前端框架不支持除 get，post 之外的请求方式，比如百度小程序就只支持 get，post |
 | 53 KuroNekoFan 2020-01-02 18:19:37 +08:00 个人比较喜欢 search param，也很少用 path param |
 | 54 cloudyplain 2020-01-02 18:20:18 +08:00 /back/remark/{termId} 这种风格，在 metrics、tracing 时都及其蛋疼，忽略一个很容易内存爆掉，正则分析也是资源杀手，建议少用。 |
 | 55 jjshare 2020-01-02 18:25:06 +08:00 实话说，我就非常非常反感 一个 URL 通过 method 来区分 沟通起来费 我个人在实践里面，和前面别人提到的一样，API 只用 POST，URL 里不加参数，统一 data 传参数 |
 | 56 wangyzj 2020-01-02 18:38:06 +08:00 公司有规定就按照规定来呗 |
 | 57 beastk 2020-01-02 18:46:38 +08:00 via iPhone 记得遇到一个坑，php5.x 版本，用 put 方式传 form 表单二进制数据时，得自己获取数据。 |
 | 58 jss 2020-01-02 18:57:17 +08:00 via iPhone 这年头搬砖的都来敲代码，就不要太讲究了… |
 | 59 wc951 2020-01-02 19:00:35 +08:00 via Android 你要反思一下为什么只能呆在这么 low 的团队里了 |
 | 60 finian 2020-01-02 19:11:23 +08:00 说不规范是不符合团队的规范，没毛病，又不是只有 RESTful 一种风格 |
 | 61 littlewing 2020-01-02 19:13:43 +08:00 没有谁对谁错，重要的是统一 就像我厂 golang 的 const 变量都是 大写+下划线，不符合 go 官方风格 |
| 63 jss 2020-01-02 19:18:34 +08:00 via iPhone 杂牌军宗旨：能用就行 |
| 64 wc951 2020-01-02 19:28:37 +08:00 via Android 1 @finian 显然你是在曲解我的意思，low 的是认为达到 restful 成熟度第二级的 api 不规范，况且以该团队表现出的保守来看他们并不会使用更加激进的 graphql |
 | 65 tiedan 2020-01-02 19:34:28 +08:00 全用 post |
 | 66 alcarl 2020-01-02 20:13:29 +08:00 1 今年搞了 n 次安全检测的。。。，说句心里话你们同事说的不规范，不是代码层面的规范，是安全层面的。。。。。。。比如 tomcat 之类的容器默认是禁止 delete 这类 http 方法的，自己打开如果控制不当会导致安全问题。安全的规范和防护设备的监控规则也都是就紧不就松的，摊子铺大了什么都是遵循这个逻辑。这方面可以看看阿里的 java 开发手册。不要动不动上火，等发现自己不知道的太多，就不好意思这样杠了。。。。。厂子越大台面越高代码之外的东西越多 |
 | 67 tedderchan 2020-01-02 20:19:18 +08:00 有什么， 我们全部用 post, get 就连 get 我们都很少用 别扯什么缓存规范，nobody cares |
| 68 tedderchan 2020-01-02 20:20:49 +08:00 @jjshare 真心统一，最恶心资源还用 post delete put 之类的来区分，直接 api 名字加上不就行了吗 会死吗？ |
 | 69 heart4lor 2020-01-02 20:29:10 +08:00 确定不是前端因为懒 |
 | 70 NakeSnail 2020-01-02 20:43:42 +08:00 我通常直接要求只能 POST，不能其它，简单，水平高低都能说通 |
 | 71 so1n 2020-01-02 20:54:54 +08:00 via Android 我想起我实习时就按标准写 REST url，结果 cdn 过不了……按照自己团队规范来就行了 |
 | 72 Biebe 2020-01-02 21:37:36 +08:00 via iPhone 3 国内大厂与国外大厂是不是不是一种大厂 |
 | 73 otakustay 2020-01-02 22:13:25 +08:00 一般都是后端框架太老了不支持，不行就不行呗没啥办法，就像前端也会和 UE 说动画一定要贝塞尔曲线的，别搞逐帧动画，类似的道理 |
 | 74 ArtIsPatrick 2020-01-02 22:48:41 +08:00 via iPhone @marcong95 咕...咕弗 QL? |
 | 76 yafoo 2020-01-02 23:09:55 +08:00 via Android get+post 挺好的 |
 | 77 freestyle 2020-01-02 23:20:12 +08:00 via iPhone 这种说法有道理的，path 参数不仅对日志分析和性能监控不利，而且调用方每次拼 path 也是一种额外消耗，还要考虑转义和 get 参数长度限制. |
 | 78 gitJavascript 2020-01-02 23:22:29 +08:00 之前怎么玩的就怎么玩喽，多大点事 |
 | 79 luozic 2020-01-02 23:25:14 +08:00 via iPhone 只要规范一致，按架构变化演进就行，如果是拿着十年前的不知道哪个废纸篓里面的黑魔法当独门绝技，你倒是要多注意是不是过时的垃圾坑。 |
 | 80 HanMeiM 2020-01-02 23:26:19 +08:00 1 这东西也不只是只有 RESTful 一种规范 |
 | 81 hiya5 2020-01-03 00:31:31 +08:00 。 |
 | 82 dodo2012 2020-01-03 01:36:33 +08:00 这问题争很久了，反正我是一直 RESTful， |
 | 83 zappos 2020-01-03 01:47:46 +08:00 via Android rest 死全家 |
 | 84 binux 2020-01-03 02:34:18 +08:00 1 这就是为什么在国内「 35 岁以上不要」的原因。 |
 | 85 SakuraOjosama 2020-01-03 08:04:19 +08:00 我还见过啥都用 get 的，什么 put?delete?那人完全没听说过的样子 |
| 86 SakuraOjosama 2020-01-03 08:05:35 +08:00 @unco020511 套个 json/狗头 |
 | 88 GlobalNPC 2020-01-03 08:37:17 +08:00 via Android 听着这么像携程呢 |
 | 89 murmur 2020-01-03 08:43:17 +08:00 put 和 delete 除了语法上优雅还有其他意义么？叫 delete /api/user 就比 post /api/delUser 低人一等？ |
 | 90 Reficul 2020-01-03 08:45:50 +08:00 via Android 又不是不能用.jpg |
 | 91 xuanbg 2020-01-03 08:58:21 +08:00 路径参数能不用还是不要用了，真的不友好。总之，使用什么风格不重要，统一的规范最重要。 |
 | 92 nnqijiu 2020-01-03 09:01:54 +08:00 post 还不够你用吗，狗头 |
 | 93 linbingcheng 2020-01-03 09:04:14 +08:00 1 他说的没错呀。put 和 delete 在属于不安全的 http method，在 web 安全开发领域是禁止直接暴露的使用的，连 web 容器都得禁掉支持这种 method 的特性，哪怕你认为这个不会有安全漏洞，但是会导致你的产品在某些安全扫描厂商验收时通不过 |
 | 94 salamanderMH 2020-01-03 09:04:16 +08:00 也没啥关系。 |
| 95 xuanbg 2020-01-03 09:06:23 +08:00 @rimutuyuan 有人把 http 当做传输协议 http 本来就是传输协议啊，Hyper Text Transfer Protocol 直译过来就是超文本传输协议，写得明明白白。web 是 web，http 是 http，两者并不相等。 |
 | 96 zhjie 2020-01-03 09:08:07 +08:00 楼主是不是用 get post put delete 写了 crud 库啊，所以才这么上火？ |
 | 97 wizardoz 2020-01-03 09:19:33 +08:00 @unco020511 elasticsearch 一开始就是用 GET 带 Body 来传查询语言，后来用 Post 也支持了。 |
 | 98 sunzongzheng 2020-01-03 09:20:07 +08:00 via Android 我司 java 说 get 请求解析参数麻烦，一般一律 post |
| 99 marcong95 2020-01-03 09:23:58 +08:00 |
 | 100 cryingsky 2020-01-03 09:28:18 +08:00 put 和 delete 为什么不安全 |
Select Language