对接同事的接口,他定义的所有接口都是 post 请求,理由是 https 用 post 更安全

2022-01-23 10:29:15 +08:00
 caicaiwoshishui
之前习惯使用 restful api ,如果说 https 只有 post 请求是安全的话?那为啥还需要 get 、put 、delete ?我该如何反驳他。
28110 次点击
所在节点    程序员
195 条回复
Cbdy
2022-01-23 13:13:41 +08:00
他说的是对的
XCFOX
2022-01-23 13:15:19 +08:00
GraphQL 大法好 https://graphql.cn/
GraphQL 就没有 get 、put 、delete ,全是 post ,根本不纠结。
aliveyang
2022-01-23 13:16:52 +08:00
就是懒
cumt21g
2022-01-23 13:17:34 +08:00
我还见过 header 里塞 json 的呢
looplj
2022-01-23 13:19:14 +08:00
@0xsui #59 见过,想骂人,国外的 quickbooks ,API 查询直接写 SQL 。这可是国外流行的财务软件,母公司市值 1500 亿刀,
h82258652
2022-01-23 13:22:49 +08:00
你应该反驳你同事,POST 还不够的,应该要对参数进行加密,加时间戳,防止回放攻击
dawniii
2022-01-23 13:23:12 +08:00
全用 post 确实能减少很多沟通成本,请求参数全都用一种固定的 json 格式,这样大家都方便。

get 请求 url 上面携带参数确实会提高一些沟通成本,比如遇到的几个情况:

1. 如果参数是数组,大家要协商用什么形式传递大家都方便处理,不同框架的处理情况可能不一致
2. 如果参数值中有空格或者百分号等会转码的字符,双方的 urldecode 方法和规范要一致

还有几个想不起来了。但是自从全用 post 传递 json ,这些问题都不用沟通了。
BQsummer
2022-01-23 13:24:36 +08:00
同意 47 楼。
1. 复杂业务场景按照 restful 设计不可能完全符合
2. 我负责监控告警,把 id 带到 url 上真的很难处理
0xsui
2022-01-23 13:28:15 +08:00
@ZSeptember 去年看见普联软件一个财务报销线上系统这么玩,大公司系统成型,招毕业实习生就搞出这种怪物(;-_-)ᴇᴍᴍᴍ
astrorobbie
2022-01-23 13:32:03 +08:00
之前在 IE 里遇到一个问题,如果 GET 请求的参数含有中文,会变成乱码,后来就都用 POST 请求了
dcsuibian
2022-01-23 13:43:41 +08:00
先不说 restful 的事,“https 用 post 更安全”这个论点是错的。因为 https 里,信息都加密了,外部甚至连用的什么请求方法都不知道,要有问题就是加密前解密后的问题。

比较安全性必须得说清楚原因。

post 比 get 安全是真的,因为请求参数如果放在 url 里,那么浏览器的收藏功能啥的就有可能把这个 url 记录下来,而不是因为 https 传输过程的问题。而且,对于用户名密码这种场景 get 不适用,但对分享链接就很合适(比如搜索引擎,把关键字放在 url 的查询参数就很合适)。因此,对应的场景使用对应的请求方法是有道理的。

但 post 和 put 、patch 什么的,把信息放请求体里就没有这个问题。
offswitch
2022-01-23 13:48:26 +08:00
@astrorobbie 这跟 get post 无关,编码问题
0xsui
2022-01-23 13:52:58 +08:00
@astrorobbie 这种情况 Base64 转一下再传
0xsui
2022-01-23 13:53:33 +08:00
@astrorobbie 或者 url encode 一下
Jooooooooo
2022-01-23 13:57:48 +08:00
他的理由不对

他这么用没啥问题, 一把梭挺好的, 也不会带来什么额外成本, 反倒是 get post put delete 乱来, 每个接口还要小心区分, 何苦呢, 也不带来新信息
mrcode
2022-01-23 13:59:56 +08:00
去年也遇到了个同事全部定义成 POST ,原来是因为底层 RPC 框架省事的原因。。转念一想 POST 确实会少很多坑,如果能克服没对齐规范带来的内疚感没啥大问题,甚至还能避免 URL 过长导致解析出问题的 BUG 。
换个角度说,很多接口喜欢在返回值里添加状态码,那又怎么定义请求失败了呢?查找一个不存在的资源是提示业务的状态码还是 HTTP 规范的?我觉得都不重要,关键是在项目中形成一套规范,方便大家理解就行
chenzhekl
2022-01-23 14:00:41 +08:00
全 POST 没什么问题,RESTFUL 也不用这么教条主义。
mrcode
2022-01-23 14:01:45 +08:00
规范本身就是希望节省代码和理解成本,权衡利弊后怎么使用规范完全是研发自己的权利
dcsuibian
2022-01-23 14:03:54 +08:00
还有,restful 是个好的参考标准。虽然实际中设计的 api 很难完全符合 restful 标准(有个词叫“反模式”?),但在能使用 restful 的时候就应该使用。

为什么?因为每个人的设计思路都不一样,不遵照一个标准就会遇到各种牛鬼蛇神。
你今天可以抛弃 http method 不用。推而广之:
1 、url 只有一个请求路径字符串,太弱了,我要定义自己的结构,自己写请求分发器发到不同的处理方法。
2 、https 是公开的,安全性不行,我要用自己的加密方法。
3 、反正是传递信息,websocket 双向通讯,不比你 http 强

restful 能在各种 api 设计里脱颖而出,如果真的有人认为自己的接口标准能打败他,那自然更好,赶紧亮出来给大家开开眼。
4BVL25L90W260T9U
2022-01-23 14:10:37 +08:00
感觉 V2 上不看题目,上来就是无脑输出自己观点的也是越来越多了呀。

ls 说的对,他这个理由肯定是不对的,post 更安全顶多是敏感信息不会打在日志里,跟 https 没有半毛钱关系。

即使这样,全部都用 post 也是值得商榷的,这取决于你服务的类型,而不是无脑 post 就对了。

- 对于资源型的服务,或者说 CRUD ,那显然是 Restful 更加语义化一些,全部 post 想想就不是很合理。
- 对于 RPC over http 型的服务,全部使用 post 是值得推荐的,实际上像是 jsonrpc 这种标准定义也都是 post 。

最后,具体选那种方案也得考虑你在这个项目中什么角色,如果不用你维护,就是帮帮忙,那同事愿意咋样就咋样呗。如果最终是你维护,那最好要坚持你的正确意见,不然那不是给自己挖坑么?

希望 V 友们好好审题啊,别只输出情绪。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/830030

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX