1
seers 221 天前 via Android 3
我只说一点,大部分漏扫等保公司只会允许 GET/POST ,然后客户只会让你整改,当然自己玩随便
|
2
cxsz 221 天前 1
我自己写的基本都是 get ,用起来方便,浏览器输入一下就行,公司规定是统一 post
|
3
flyqie 221 天前 1
每隔一段时间就会出现这样的讨论,建议先左上搜索一下
看个人喜好和环境要求,我个人是 200 + post ,http_code != 200 问题肯定都是基础设施,跟我没关系。。 |
4
0o0O0o0O0o 221 天前 8
|
5
drymonfidelia 221 天前 1
|
6
OutOfMemoryError 221 天前 1
@seers #1 +1 我们之前遇到一个“安全检测”就是这种要求,只好做了个变通方案,前端传 Header 到 nginx ,然后 nginx 处理一下发到后端
|
9
Inzufu OP @seers @OutOfMemoryError 那看来还是用 GET POST 比较好,我个人感觉 PUT 、PATCH 、DELETE 这三个 methods 其实完全可以用 POST 代替。
|
10
infun 221 天前 1
臆想的规范,现实世界比臆想世界复杂的多,抽象出来的方法很多时候都是脱裤子放屁
个人支持 get post 全包 |
11
winterpotato 221 天前
🤣我们公司就不一样了,我们公司全部 get 数据通过 headers 发🤡
(开个玩笑) 当然遵循 restful 语义了 |
12
securityCoding 221 天前 via Android
谁用 restful 我会暗自骂他傻 233
|
13
agagega 221 天前
即使环境不能使用 PUT/PATCH/DELETE ,用 POST 模拟也是好的,或者就用 POST 表达发起某个事务的含义也完全没问题。怕的就是一股脑全用 GET ,创建订单也来个 GET ,这就无可救药了。
|
14
luodan 221 天前
小白请教那些全用 GET 的同学一个问题,用 GET 不是大家都看得一清二楚了吗?
|
15
Kumo31 221 天前
都用,RESTful API ,当然 RESTful API 的表达能力有缺陷,难以满足复杂业务场景,还需要结合 Google 的 Custom methods: https://google.aip.dev/136
|
16
icy37785 221 天前 via iPhone 13
虽然别人问我接口怎么定义,我推荐 RESTful ,自己的项目只用 get 、post ,甚至看到 restful 还会发笑。
|
17
siweipancc 221 天前 via iPhone
理论中:新建记录 post 返回 201 重定向到数据。
实际操作:返回 200 加个 ok 状态码。 问就是流程越简单 bug 越少。 |
19
raycool 221 天前
post 一把梭吧
|
20
zeromake 221 天前 via Android
我之前也想各种 put ,delete 用起来,然后客户端一对接说客户端框架封死了只能用 get ,post😂
|
21
maymay5 221 天前
post 走全部
|
22
lujiaxing 221 天前
视情况.
如果是系统内互相调用, 一般就是 get/post. 没啥必要搞什么 put delete... 如果是开放 API, 而且本身也比较简单 (例如只是开放个 WEB 接口给三方读写数据之类的), 可以用 RESTful API. 我个人是不喜欢 RESTful 这个风格的. 太简陋了, 对于一些复杂的业务接口来说, 要么把 URL 搞得极其抽象 (如: /api/v3/userrelationshipinorganization/7333/8964) 要么把接口拆散拆得跟被爆破了一样, 然后让前端做整合层. 无论哪种其实都很恶心. |
23
IdJoel 221 天前
DELETE PUT 多好用,要不 URL 整那老长多难受
对接的开发一眼就能看出来接口是干啥的,多直观啊? |
24
wangkun025 221 天前 via Android
我选择遵守 restful
|
25
caomu 221 天前 via Android
|
26
cmdOptionKana 221 天前
RESTful 是自找麻烦
|
27
lff0305 221 天前
以前做项目见过的:
客户有奇葩的防火墙/负载均衡,对于 1. 非 Get Post 请求,高峰期不能保证 QOS ,要对 Get Post 让路 2. 非 2XX 返回值,会把 response 封装成类似 upstream error:<原始的 body> 而且可能 body 还会被截断 所以为了适应客户把项目做下去只能全部 GetPost ,用 200 返回,再把错误信息放在 Body 里面 |
28
cmdOptionKana 221 天前
RESTful 就是非常典型的学院派风格,理论上很优雅,很美,但实践中弊大于利,碍手碍脚。
|
29
afxcn 221 天前
我们就用 RESTful 风格的,国内国外的项目也没遇到什么问题。
|
30
aragakiyuii 221 天前 via Android 30
|
31
MrDarnell 221 天前 6
还是要走 restful 规范,现在很多公司规定 post 其实是一种负责人能力低下的表现,但碍于自尊心,拒绝承认
|
32
layxy 221 天前
get,post,put,delete 四个都用,之前遇到过前端会吐槽说分不清接口,path 都一样容易调错
|
33
IvanLi127 221 天前
反正我们严格遵守 RESTful ,等保和安全都过得去。我感觉这些请求方法都挺常见的
|
34
wangtian2020 221 天前
都可以,市面上常见的两种接口风格
|
35
proxychains 221 天前
GET 查询
POST 新增 |
36
hash 221 天前
就像一楼说的,POST 一把梭是有他的原因的,但我仍然认为 POST 一把梭是傻逼
毕竟没有任何一个人一辈子只做政府外包 |
37
jonsmith 221 天前
我用 get 和 post ,请求数据用 get 、更新用 post ,也见过全部用 post 的,但是全部 get 应该做不到。
|
38
proxychains 221 天前 1
GET 查询
POST 新增 PUT 修改 DELETE 删除 |
39
bitmin 221 天前
大部分接口都很简单,省得想名字,/、/{id} GET POST DELETE PUT PATCH 对应增删改查多简单
复杂接口另说,当然是随机应变 还好我们接口都是自己用,除了老板没人指手划脚 |
40
me1onsoda 221 天前
现实的情况很复杂,一个新增的过程可能也有查询删除修改
|
41
Dlin 221 天前
有规范大家不使用,所有大家才会觉得碍手碍脚。
|
42
cnevil 221 天前
http 标准中 delete 方法也不是给你这样用的吧
我觉得遵循国际标准比那什么 restful api 标准理由要充分的多。。 |
43
jydeng 221 天前
我们用 gql
|
44
shuax 221 天前
老夫只会 post json 一把梭。
|
45
wanguorui123 221 天前
JAVA 里面 POST 最简单和通用,GET 简单的查询可以用用
|
47
shyangs 221 天前 2
@MrDarnell
RESTful 是風格(style),不是規範/標準(standard). 標準有標準文件,比如 JSON 的文件 ECMA-404 是由 ECMA 編寫. RESTful 是一份 2000 年的博士論文出來的風格,早就過時了,這位博士生可能連 XML(1998), JSON (2001) 都沒寫過,只好什麼都往網址上塞,這種過時風格被追捧太滑稽了. 連 JSON-RPC (2005) 都比 RESTful (2000) 新穎. |
48
Van426326 221 天前
一楼说的对 我也不想改啊 等保过不了有啥办法
|
49
echo0x000001 221 天前
很多人觉得 restful 不好用是因为没有工具,django 的 DRF 框架用起来不用太爽,节省很多代码。
|
50
ShinichiYao 221 天前
get 也别要了,post 一把梭
|
51
ben666 221 天前
get post put delete 都是常用的
本来开源网络性能测试仪 dperf 只支持 get ,有人提 issue 希望支持各种 method https://github.com/baidu/dperf/ |
53
o562dsRcFqYl375i 221 天前
get -> 读
post -> 写 完事 |
54
z1154505909 221 天前
我特么要喷一个腾讯,文档写的 get,例子也是 get,我用 get 请求返回我访问未知的 url,垃圾腾讯
|
55
DOLLOR 221 天前 via Android
@proxychains
login 应该用哪个呢? |
56
qa2080639 221 天前
get 传值有类型问题 null false true 不好表示,所以我全用 post 传 json 一把梭 别人还在研究怎么定义接口我已经下班了
|
57
Laobai 221 天前
只能 post 一把梭,否则扫描过不了
|
58
sZiUp3ETjqDgSF2U 221 天前
查询用 get ,其他 post 一把嗦,运维淡疼在网关把其他都拦掉了。
|
59
qbmiller 221 天前
2B 项目。老老实实 get post
|
60
zxkxhnqwe123 221 天前 1
原来 RESTful
一段时间 GET POST 现在 POST |
61
thinkershare 221 天前
这种重复提问,管理员应该禁止掉。
|
62
Torpedo 221 天前
restful 不是一个好风格。因为实践里,我见到的每个自称 restful 风格的 api 都有不同。特别是一些模糊行为
|
63
MrKrabs 221 天前
RESTful=野鸡
|
64
zw1one 221 天前 1
post 一把梭真的很香,代码也很健壮,也很方便复制粘贴。省下来的时间可以摸鱼,活动下颈椎,让你身体精神保持健康。
|
66
daiv 221 天前
@raycool @maymay5 @shuax @ShinichiYao @Laobai @zxkxhnqwe123 @zw1one 如果全部用 Post, 那么路径如何设计更合理?
创建( Create ): POST /api/v1/user/create 更新( Update ): POST /api/v1/user/update 读取( Read ): POST /api/v1/user/read 列表( List ): POST /api/v1/user/list 操作( Operate ): POST /api/v1/users/operate (Delete, HardDelete, Restore, Copy 等等...) 各位大佬有什么建议吗? 这样是否合理. |
67
leaflxh 221 天前
无非在于错误在哪处理
.then(res=>{ res.code === 200}) 还是 .catch(err) |
68
olaloong 221 天前
稍微复杂点的业务用 RESTful 都是一团糟,毕竟一次调用里操作的可不止一个资源。硬套 RESTful 的话,要么按资源拆分请求,那复杂均衡、事物就糟了,要么在一个资源操作里隐性操作其他资源,时间一长就变成屎代码。
见过几个项目设计之初想用 RESTful ,最后都变成了特色 RESTful 的杂交项目。 |
71
crackidz 221 天前
取决于你客户端开发的水平😂
|
72
JenJieJu 221 天前
graphql ,前端自己撸
|
73
9c04C5dO01Sw5DNL 221 天前
必须是考虑语义、Safe 和 Idempotent ,这些性质和 restful 无关,纯纯 rfc2616 中定义的啊。。。
|
74
chendy 221 天前
全部 POST ,因为要兼容 ie ,put 之类的不敢用,get 有时候缓存了全麻
全部 200 ,因为对接的前端喜欢,反正写起来都一样 |
75
momo24672 221 天前
GET 读
POST 创建 DELETE 删除 PATCH 更新 POST 一把梭的全是 SB/垃圾 |
76
lesismal 221 天前
> POST 一把梭的全是 SB/垃圾
@momo24672 不选择 Restful 的人会越来越多, 注意, 我说的是"不选择", 而不是"放弃", 因为 Restful 本来就不是必选项. 另外, 别太自信了 |
78
proxychains 221 天前
|
79
picone 221 天前
|
80
wjfz 221 天前
非要 post 也行,像#66 那种也还算清晰。
关键是错误处理,用 200 状态+错误码,前后端约定几十个错误码是一件及其傻逼的事情。 |
81
WashFreshFresh 221 天前
@picone 用户会解决 手动狗头
|
82
hxysnail 221 天前 2
大家是不是对 Restful 有什么误解,Restful 多出来好几种 method ,是 GET/POST 的超集,不存在能力比 GET/POST 更弱吧?
我维护的项目,采用 Restful 协议,迭代了好多年,没发现有什么坑啊 比如,一个资源普通的增删改,能有什么问题? POST /Datas # 新增 GET /Datas/{id} # 查询 PUT /Datas/{id} # 修改(整体替换) PUT /Datas/{id} # 修改(部分更新) DELETE /Datas/{id} # 删除 对于特殊的业务逻辑,我们约定好一个在某个资源上做的一个动作,范式如下: POST /some/resource/path/_action 举个例子,我们想让数据支持软删除: POST /Datas/{id}/_markDeleted # 软删除(打标记但数据不删) 再举个例子,搜索数据集合,Body 传一个 Filter (比如 Name 符合某个正则表达式): POST /Datas/_search { "Filter": { "Name": { "$regex": "abc" } } } 最后一个例子,某条数据记录想发一条通知出来: POST /Datas/{id}/_notify 迭代了这么多年,没发现有什么所谓的业务逻辑套不进去的问题啊。 还看到一个说法说,Restful 需要写好多个接口,然后再让前端来整合?这不是典型的接口 [粒度] 问题嘛…… 站在后端的角度,接口粒度合理拆细是可以,难不成来个场景你加个接口刷一刷存在感吗?别人我不知道,我对手下的后端的要求就是合理地细,让前端可以灵活组合完成特定、个性化的业务场景。 站在项目统筹管理的角度,如有某种组合很常用,你让前端自己一遍遍地去拼接也不合理吧?这个时候不就提供一种粒度更粗,但更固化的接口出来吗?这样双方不都得到满足吗?同样别人我不知道,我对手下的前端的要求,就是接口不合理,需要不断重复组合的逻辑,就要反馈给后端。然后一起消除重复性。 总结:①后端接口粒度在合理的前提下,尽量细;②对于常用组合,再封装更固化和个性化的粗粒度接口。 还有一个问题,说前端框架封死了只能 GET/POST……挖槽,前端垃圾关你啥事?关 Restful 啥事?能 diss 他就 diss 他,不能 diss 他的就捏着鼻子接受吧。 还有人提到,说客户公司只允许用 GET/POST ,怎么说呢?都做乙方了,当然没办法了,甲方说啥就是啥……但这是你还是有办法在 POST 方法的基础上,自行定义一套给 Restful 类似的协议,无法是把原本用 Method 来表达的信息搬到 body 里而已。举个例子: POST /Datas/{id} { "Action": "UPDATE", "Data": …… } 因此,重点不是 Restful or GET/POST ,重点是接口要满足一套统一而且规范的范式。 我同意有人提到说 GET 、POST 是负责人不负责任的做法。就 POST 请求,然后 path 爱怎么定就怎么定,数据爱怎么传就怎么传,最终一定是座代码屎山。举个例子,我合作过的项目,就纯 POST 的,但接口五花八门。同一种数据,不同接口返回的格式有些字段名还不太一样,一不留神就被坑到。这就是垃圾。被坑的次数多了,别人就会抗拒跟他合作。 据我的观察,绝大部分程序员,特别是外包根本就没有驾驭抽象范式的能力。没能力也就算了,不少人还喜欢浮于表面,夸夸其谈。说到底,“无规则不成方圆”,这么简单的道理,我们几千年前的老祖宗都懂。但不少所谓的新时代开发工程师,还在重复着开发一个垃圾接口,再写一份垃圾文档来描述这个垃圾接口的死路。 |
83
zhwguest 221 天前
月经贴啊。。。。
|
84
woodfizky 221 天前
合适就好,当你有选择的自由的时候都好说,反正没必要因为要强行套 restful 给自己上条条框框上枷锁,取其精华去其糟粕。
|
85
ivvei 221 天前
RESTful 就是 SB 玩意。
|
86
nekoneko 221 天前
|
87
F7TsdQL45E0jmoiG 221 天前
擦,那些所谓的等保+安全公司基本快把 GET 都禁掉啦,已经堕落到全 POST
|
88
ivvei 221 天前
@hxysnail
五花八门: POST /Datas # 新增 POST /some/resource/path/_action PUT /Datas/{id} # 修改(整体替换) PUT /Datas/{id} # 修改(部分更新) 不要说别人就五花八门,说自己就是合理约定。 |
89
jiayouzl 221 天前
按照规范肯定是 PUT 、PATCH 、DELETE.当然 get,POST 也可以,一切看自己需求.
|
90
romisanic 221 天前
选择用不用一套规风格也能用出优越感来,神奇
更用此来评定与自己不同的别人是 SB/垃圾,这才是真正的 SB&垃圾啊 |
91
ming7435 221 天前
X 银行安全团队只接受 GET / POST, 其他一律视为漏洞
|
92
cxxnullptr 221 天前
建议学习一下 restful ,用起来比纯 POST 爽多了
|
95
momo24672 221 天前
用了 K8S 之后,其实更推崇谷歌这一套设计 https://cloud.google.com/apis/design/resources
|
96
zhao8681286 221 天前
|
97
jackerbauer 221 天前
post 吧,没那么多事,我们的为了实现业务的
|
98
icy37785 221 天前 via iPhone
@momo24672 #9 你一边说可以选择 RPC 或者 GraphQL 了一边又说 POST 一把梭的肯定是 SB 。
那你打算怎么用 GraphQL 。 |
99
hxysnail 221 天前 2
@ivvei #88 咱不杆哈
①部分修改那里,我把 Method 打错了,应该是 PATCH ②我不知道前面那里那个地方五花八门了。拿我们自定义的 action 部分来说,我们至少保障 action 是一致的,想搜索数据就调_search 接口,比如: - POST /Datas/_search - POST /Hosts/_search - POST /BusinessSystems/_search 再比如,我们所有软删除数据接口,action 都是_markDeleted ,不会 A 叫 softDelete ,B 叫 softRemove - POST /Datas/{id}/_markDeleted - POST /Hosts/{id}/_markDeleted - POST /BusinessSystems/{id}/_markDeleted /some/resource/path 只是想表达有些 action 是在数据集上,比如/Datas ;有些 action 是在单个数据记录上,比如/Datas/{id};甚至有些 action 是在子数据上,比如/Datas/{id}/SubDatas/{subid}。 哪里五花八门了? 你不会看到/some/resource/path 跟/Datas 不一样就觉得五花八门吧…… 我通篇都在强调统一一致的范式,而不是在强调就应该采用跟我一样的思路。我不在乎范式是什么,我反对前后不一致,没有任何规则的 POST 而已。 “不要说别人就五花八门,说自己就是合理约定。”你这么说不就想说别人双标嘛……还真不是…… 今天想起要回这个贴,是因为上周我手下的人刚别其他项目的接口坑了一下。他们告诉我的人,要换个接口,返回的数据字段没变。我的人就去换了,因为对方说接口一样,数据字段没变,他们就偷懒没验证。结果上生产就出了个小问题,因为数据有个字段结构不太一样…… 同一个字段,有一个接口是返回逗号分隔的字符串,另一个返回一个字符数组……理论上,同一种数据,不同的查询场景,返回的数据字段结构没必要不一样吧?这才是我强调的五花八门。 然后,我在自己项目的开发群里强调了范式规范,不知怎么发图片,直接贴我说的文字: 理论上,接口再垃圾,只要我们验证充分,问题肯定不会到生产上。 就算接口不好,最多也只是在开发阶段被坑,影响你的研发效率而已。 冤有头,债有主,谁坑你就去怼谁。 我以前经常跟你们强调,字段命名要前后一致,严禁五花八门,最近几次缺陷就是典型的案例。质疑别人前,我们自己要先做到这一点。 注意看, [质疑别人前,我们自己要先做到这一点。] 我们对自己的水平心里有数。 |