同事说:后台接口不能使用除 post/get 之外的方法,path 里不能带参数
unco020511 · 2020-01-02 16:42:17 +08:00 · 22172 次点击这是一个创建于 1820 天前的主题，其中的信息可能已经有所发展或是发生改变。
我写了接口文档,尽量按照 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 为什么不安全
|
Select Language