我写了接口文档,尽量按照 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
wisdom 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
rimutuyuan 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
infun 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 为什么不安全
|