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

[unco020511]

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

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

[killergun]

听老大的

[luckyrayyy]

少数服从多数，费这个劲干啥。

[jowan]

并不一定非要 REST 虽然我司用的是 :)狗头
前端抱怨大概是因为非 200 状态 比如 422 419 404 要捕捉异常处理 哈哈

[unco020511]

地址:某二线不大不小的厂

[lazyfighter]

老子就这么写，爱用不用

[learnshare]

六字送上，该忍就忍了，不专业才是正常的

[Cyron]

谁说了算听谁的

[Leonard]

我还见过后台全用 post 的，get 都不用

[ysyk]

很正常，我们这边，前端说如果只用 post 是最好的

[lihongjie0209]

没什么问题, 统一就好

[MatthewHan]

拿阿里、百度等等的一些接口文档给他们看

[mcfog]

V 站著名月经贴，楼主你这样写火不起来（滑稽

搜索 site:v2ex.com restful 了解更多

[est]

path 里不带参数 一时爽。。

nginx 日志分析火葬场。。。。

[marcong95]

那你就直接给它来个

POST /api
{"method": "get", "type": "remark", "termId": "{termId}"}

POST /api
{"method": "delete", "type": "record", "id": "{recordId}"}

[unco020511]

怎么写其实无所谓,但是说不规范我就不乐意了,且一副你不懂的表情

[yidinghe]

但是 GET 里面传 BODY 也不合适

[unco020511]

@marcong95 楼主原来做移动端的时候还真见过这种,全部都是一个 url,然后参数 method 来区分具体业务

[a719114136]

就一个规范，用什么都行。 之前有规范了就按照之前的。

选择规范的标准就是简单，说实话我也不喜欢 RESTful 那套，直接 post/get 就够用了 ，弄一堆 method 那么复杂。

另外 path 里带参数，这种 url 确实便于理解，我以前也挺喜欢这种风格的。但对后端来说，有的框架不能匹配这种 url ；对于前端来说，不利于代码结构化。所以现在也放弃了 path 里带参数

[unco020511]

@yidinghe get 里传 body?咋传

[gwybiaim]

REST 很重要的一条是面向资源，你可以按照常见的 rest 风格来，也可以设计自己的 rest 规范

[lihongjie0209]

@unco020511 #19 传不了, 只能用 query string http://xxx.com/api?a=1&b=2

其中
/api 是 path
?a=1&b=2 是 query string

[unco020511]

@a719114136 全部用 post/get 我能理解,但是 path 不能带参数就有点奇怪;

path 可以理解为资源定位,那 id 放在 path 里获取资源不应该更合理吗;

还有前端框架不支持也有点牵强,我原先做移动端+web,都是支持的,且新框架一般都支持的很好,比如 android 的 retrofit

[MaPeiren]

可以不这么做，但是不能说你不懂阿，这真的上头

[unco020511]

@mcfog 搜了一下发现了新天地,哈哈

[marcong95]

@unco020511 #17 十分经典的用来杠“反 RESTful”群体的例子了

[ic2y]

@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 协议。

你不得不推动 每个团队来支持你的需求，这个等待 是很麻烦的。

[a719114136]

@unco020511 看错了吧，我说的是后端。
比如：
* /user/ {user_id} /update
* /user/ {user_id} /delete

这种类型的 url，有的框架是不支持的

[passerbytiny]

不需要说服。若接口定义、实现、权责人全在你，你只管照自己走，爱用不用。若定义、实现在你但权责人不是你，准备跑路。

当然有几点要注意：
一，RESTful 是一种编码风格而不是工具，只存在用不用，不存在尽量用，若你不能让所有接口都遵循 RESTful，那就不要用。
二，RESTful 与 HTTP 相互适应，但与 HTML 并不相互适应，APP、好的前端框架能够很容易的适配 RESTful 接口，但一般的前端框架以及不用框架的 Web 开发，是只认 get、post 不认其他请求的（严格的说，底层技术是支持其他请求的，但是框架设计思想上不支持）。
三，如果接口是 RESTful，那么底层既是不是领域驱动设计，也要对此有所了解，否则你在 URI 命名上绝对会遇到矛盾。

[unco020511]

@a719114136 27 不好意思看错了.可能后端部分框架确实不支持吧

[unco020511]

@ic2y 26 这样说挺有道理,原先我没有想到这些

[Raymon111111]

习惯跟随团队

[Raymon111111]

如果你希望说服团队

那应该能列举这么干的坏处和按照你这么干带来的好处

一句规范打发大家毫无说服力

[opengps]

这么做很好，很多人不知道 put，delete。不瞒你说我工作 8 年了也没写过表单的 put，delete 方法

[artikle]

@unco020511 Path 带参数 有想过接口日志统计怎么处理吗

[Raymon111111]

你可以从 研发效率, 出错概率, 代码易读性, debug 难度, 测试覆盖 等等角度阐述你的观点

(带来收益的事情才去做

[passerbytiny]

@ic2y #24 你说了那么多问题，总结起来就一句话：改起来好麻烦。如果一个大厂把这些当问题，那么这大厂要么是假的，要么“老且不能饭”。

[wisdom]

他这样要求说实话没毛病

[szq8014]

我猜后台是 php

[szq8014]

emmm 竟然是 java 版块。。springMVC 天然支持 restful 为啥他们不会用……

[randyo]

反正只用 post 前端没意见，反正都是后端处理数据🙄

[crs0910]

@unco020511 #19
@lihongjie0209 #21
https://tva1.sinaimg.cn/large/006tNbRwgy1gaicfyyousj31dl0u0qbc.jpg

[evlos]

你同事说这样不规范，就显得他很弱智了

[ic2y]

@passerbytiny 我回复了这么多，不是说不能实现。企业都是讲“成本”的，不是为了支持黑科技或者新特性。 成本：不光是 开发人员的开发成本和接入成本、还有服务器（ client 和 server ）的内存消耗和 CPU 消耗。

如果支持 RESTful 风格 很容易支持的话，早就全支持了。 业务方不允许你的采集程序占用额外的内存和 CPU，自己部署的中间件平台为了额外的模式提取需要付出性能代价 而加机器。这些个都是成本制约。

如果 RESTful 风格 在没有上下文的前提下，很容易像 POST 一样提取模式，无其他明显成本消耗，就不会这么不建议了。


api?k1=v1&k2=v2 (没有上下文，各个系统能快速解析)

与

api/k1/v1/k2/v2 或者 /mock/a/k1/v2 （没有上下文，面对海量的各种地址的 URL 请求，需要付出额外的资源进行解析）

[zhaohua]

@szq8014 后台 php 的话就全部都是 get 了，我个人觉得只使用 get post 的简易 restful api 挺好的

[rimutuyuan]

有人把 http 当做传输协议，自己在 body 中定义业务
总之，能正常使用就可以了

[chenliangngng]

站在前端的角度，delete 永远都不应该用，put 有风险应该在安全性没什么问题的时候才能考虑使用

[lihongjie0209]

@crs0910 #41
https://stackoverflow.com/questions/978061/http-get-with-request-body
自己去翻协议标准去, 没有任何地方定义了 Get 可以使用 Body

至于说框架 /标准库支持, 那是实现方的具体实现, 没有任何实际意义.

等你部署上线的时候, 你的服务器支持, 但是负载均衡不支持, 客户端类库不支持, 那么你这个还叫 http 服务器??

[IGJacklove]

这个写之前不先问一下老大的吗。。。

[IMCA1024]

那就 GET ,POST 吧
虽然我也赞同用 HTTP 动词描述操作
但有时候没办法
可能有时候运维那一层就把你的 PUT PATCH DELETE 给干掉。）

[Infernalzero]

作为规范没啥问题，做工程就是这样，不能太学院派，规范是人定的，可以根据实际需求变更。
不准用 PathVariable 最直接的原因就是访问量上去后影响匹配性能

[676529483]

反正这点我也早就服气了，restful 接口并不能带来实质的改变，本质是前端的配合、公司的包袱，反正区别也不大。状态码使用{"code": 200}同理

[zachlhb]

很正常，很多前端框架不支持除 get，post 之外的请求方式，比如百度小程序就只支持 get，post

[KuroNekoFan]

个人比较喜欢 search param，也很少用 path param

[cloudyplain]

/back/remark/{termId} 这种风格，在 metrics、tracing 时都及其蛋疼，忽略一个很容易内存爆掉，正则分析也是资源杀手，建议少用。

[jjshare]

实话说，我就非常非常反感 一个 URL 通过 method 来区分
沟通起来费

我个人在实践里面，和前面别人提到的一样，API 只用 POST，URL 里不加参数，统一 data 传参数

[wangyzj]

公司有规定就按照规定来呗

[beastk]

记得遇到一个坑，php5.x 版本，用 put 方式传 form 表单二进制数据时，得自己获取数据。

[jss]

这年头搬砖的都来敲代码，就不要太讲究了…

[wc951]

你要反思一下为什么只能呆在这么 low 的团队里了

[finian]

说不规范是不符合团队的规范，没毛病，又不是只有 RESTful 一种风格

[littlewing]

没有谁对谁错，重要的是统一

就像我厂 golang 的 const 变量都是 大写+下划线，不符合 go 官方风格

[finian]

@wc951 #59 不用 RESTful 的就是 low ？那用 GraphQL 的怎么说

[jss]

杂牌军宗旨：能用就行

[wc951]

@finian 显然你是在曲解我的意思，low 的是认为达到 restful 成熟度第二级的 api 不规范，况且以该团队表现出的保守来看他们并不会使用更加激进的 graphql

[tiedan]

全用 post

[alcarl]

今年搞了 n 次安全检测的。。。，说句心里话你们同事说的不规范，不是代码层面的规范，是安全层面的。。。。。。。比如 tomcat 之类的容器默认是禁止 delete 这类 http 方法的，自己打开如果控制不当会导致安全问题。安全的规范和防护设备的监控规则也都是就紧不就松的，摊子铺大了什么都是遵循这个逻辑。这方面可以看看阿里的 java 开发手册。不要动不动上火，等发现自己不知道的太多，就不好意思这样杠了。。。。。厂子越大台面越高代码之外的东西越多

[tedderchan]

有什么， 我们全部用 post, get 就连 get 我们都很少用
别扯什么缓存规范，nobody cares

[tedderchan]

@jjshare 真心统一，最恶心资源还用 post delete put 之类的来区分，直接 api 名字加上不就行了吗 会死吗？

[heart4lor]

确定不是前端因为懒

[NakeSnail]

我通常直接要求只能 POST，不能其它，简单，水平高低都能说通

[so1n]

我想起我实习时就按标准写 REST url，结果 cdn 过不了……按照自己团队规范来就行了

[Biebe]

国内大厂与国外大厂是不是不是一种大厂

[otakustay]

一般都是后端框架太老了不支持，不行就不行呗没啥办法，就像前端也会和 UE 说动画一定要贝塞尔曲线的，别搞逐帧动画，类似的道理

[ArtIsPatrick]

@marcong95 咕...咕挼弗 QL?

[Keyes]

@marcong95 hhhhh 这不就是 jsonrpc 了

[yafoo]

get+post 挺好的

[freestyle]

这种说法有道理的，path 参数不仅对日志分析和性能监控不利，而且调用方每次拼 path 也是一种额外消耗，还要考虑转义和 get 参数长度限制.

[gitjavascript]

之前怎么玩的就怎么玩喽，多大点事

[luozic]

只要规范一致，按架构变化演进就行，如果是拿着十年前的不知道哪个废纸篓里面的黑魔法当独门绝技，你倒是要多注意是不是过时的垃圾坑。

[HanMeiM]

这东西也不只是只有 RESTful 一种规范

[hiya5]

。

[dodo2012]

这问题争很久了，反正我是一直 RESTful，

[zappos]

rest 死全家

[binux]

这就是为什么在国内「 35 岁以上不要」的原因。

[SakuraOjosama]

我还见过啥都用 get 的，什么 put?delete?那人完全没听说过的样子

[SakuraOjosama]

@unco020511 套个 json/狗头

[darknoll]

@jowan 拦截器统一处理非 200 状态，有啥困难的吗？

[infun]

听着这么像携程呢

[murmur]

put 和 delete 除了语法上优雅还有其他意义么？叫 delete /api/user 就比 post /api/delUser 低人一等？

[Reficul]

又不是不能用.jpg

[xuanbg]

路径参数能不用还是不要用了，真的不友好。总之，使用什么风格不重要，统一的规范最重要。

[nnqijiu]

post 还不够你用吗，狗头

[linbingcheng]

他说的没错呀。put 和 delete 在属于不安全的 http method，在 web 安全开发领域是禁止直接暴露的使用的，连 web 容器都得禁掉支持这种 method 的特性，哪怕你认为这个不会有安全漏洞，但是会导致你的产品在某些安全扫描厂商验收时通不过

[salamanderMH]

也没啥关系。

[xuanbg]

@rimutuyuan 有人把 http 当做传输协议

http 本来就是传输协议啊，Hyper Text Transfer Protocol 直译过来就是超文本传输协议，写得明明白白。web 是 web，http 是 http，两者并不相等。

[zhjie]

楼主是不是用 get post put delete 写了 crud 库啊，所以才这么上火？

[wizardoz]

@unco020511 elasticsearch 一开始就是用 GET 带 Body 来传查询语言，后来用 Post 也支持了。

[sunzongzheng]

我司 java 说 get 请求解析参数麻烦，一般一律 post

[marcong95]

@ArtIsPatrick #74
@Keyes #75 我这是 xjb 写的，JSONRPC、GraphQL 之类的应该比我这东西优雅一点来着

[cryingsky]

put 和 delete 为什么不安全