对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全
caicaiwoshishui · 2022-01-23 10:29:15 +08:00 via iPhone · 25404 次点击这是一个创建于 1035 天前的主题，其中的信息可能已经有所发展或是发生改变。
之前习惯使用 restful api ，如果说 https 只有 post 请求是安全的话？那为啥还需要 get 、put 、delete ？我该如何反驳他。
 |
101
gamexg 2022-01-23 16:25:22 +08:00
我是能全部走 post 就都走，理由：
restful 不能覆盖所有情况，或者说很麻烦 get 请求的参数会被作为 url 写入日志，敏感参数就不能用 get 。 一套 get 、一套 post 需要实现两遍。 我懒得弄，直接 post 封装一套加密、签名机制，然后所有请求都用这一套机制完事，不再为 get 、post 分开实现。 |
 |
102
freakxx 2022-01-23 16:50:07 +08:00  3
不需要反驳，你看这楼里就好，
大部分人不是技术不能理解什么东西是对的，什么东西是不对的，就是没有那个能力去理解什么东西是好的，什么东西不好的。 |
 |
103
treblex 2022-01-23 16:51:10 +08:00
算好的了，遇到过 get 提交表单的吗
|
 |
104
wormcy 2022-01-23 17:18:04 +08:00
别拿安全当幌子
|
 |
105
tqyq88 2022-01-23 17:33:28 +08:00
想起以前的 leader ，用个 restful 就像得了斯德哥尔摩症一样，GET POST DELETE PUT 一定要整整齐齐。烦死了，不是一路人
|
 |
106
learnshare 2022-01-23 17:46:21 +08:00
实际上你只能选择忍受，或者 run
有些人是无法讲道理的 |
 |
107
FrankAdler 2022-01-23 18:11:00 +08:00
我一女前端同事，我让她在调用我接口的时候 query 里加上个参数，请求还是 post ，回我，加上 query 就只能用 get 了。。。我告诉她 post 的 url 也能加 query
结论就是，别指望同事的水平有多高，赶紧干完活回家抱老婆打游戏都行。。当然我的这个例子我跟人家废话了两句，是因为加在 post 的 body 里反而更麻烦。 |
 |
110
otakustay 2022-01-23 19:23:01 +08:00
没什么特别追求的无所谓，大问题无非是缓存和 Service Worker 用不了，进一步的 PWA 做不出来。不考虑这些的话，POST 就 POST 呗
|
 |
111
winglight2016 2022-01-23 20:00:53 +08:00 6
post 跟安全没关系。
post 和 get 、delete 、put 对于 http 来说，没有太大区别。 post 和 get 最大的区别，个人看来，get 被认为是读操作，post 被认为是写操作，因此 get 请求可以设置缓存（浏览器、中间件），如果是微服务 /CDN ，可以统一设置缓存条件。 回复中，那些看不起 restful 的，真的需要了解一下 restful 的来龙去脉。很多代码规范、设计范式，并不是“非此不可”，仅仅是为了“可读性”罢了。 btw ，说 get 参数会被日志记录的，这到底是什么涉密 URL ，真的不想人知道，把 query string 全部 encode 呀。 |
 |
112
iseki 2022-01-23 20:01:07 +08:00 via Android
没必要，提一下是在说服不了，就努力换团队好了
|
 |
113
seansong 2022-01-23 20:29:18 +08:00
还不就是怎么习惯怎么来么，谁强势听谁的
|
 |
114
seerhut 2022-01-23 20:36:53 +08:00
上一周我们外包向我抱怨部门其他处室的系统的接口是 GET 方法，但是参数放 body 中，你们这点小事算啥
|
 |
115
strongcoder 2022-01-23 20:52:31 +08:00
我们也是要求后台全部都用 POST,没啥 大家都方便
|
 |
116
jsjjdzg 2022-01-23 21:14:24 +08:00
restful 就是。。。不说了，全部 Post 无敌，你再研究下 restful 的设计和规范 就会发现都是垃圾。。。
|
 |
117
Vitta 2022-01-23 21:28:03 +08:00
感情写相对标准点还是错的了？ 这是服了这一群评论了
|
 |
118
zhigang1992 2022-01-23 21:36:58 +08:00
https 传输层的话，POST 和 GET 应该是没有区别的
|
|
119
zhigang1992 2022-01-23 21:38:19 +08:00
但是很多 http server 会打印请求地址到日志里面。
如果是用纯 REST 的话，可能会把一些敏感信息打印到日志里面。e.g. 银行卡号 / ID 之类的。 用 POST 的话可以避免这种问题 |
 |
120
efaun 2022-01-23 22:47:22 +08:00
如果你是他领导, 你就把他开了
如果你跟他平级, 那你就忍着 如果他是你领导, 要么做要么滚 |
 |
121
ragnaroks 2022-01-23 23:14:15 +08:00
他的说法肯定是有问题的，但是用 restful 就能承载的业务也不需要规范
|
 |
122
ZRS 2022-01-23 23:26:03 +08:00
POST 在日志里留的敏感信息少点，更安全说不上
|
 |
123
IvanLi127 2022-01-23 23:28:29 +08:00 via Android
反驳他干嘛，找人一起笑话他就行了。人越多越好，不然他是不会知道自己错了。
另外，这事直接向领导反应，领导没意见那就当一天和尚撞一天钟呗。 受不了的话，这不年底了，是时候换个环境了😏 |
|
124
IvanLi127 2022-01-23 23:34:07 +08:00 via Android
楼上居然说 POST 打印的信息少比较安全... 那你们打印日志干嘛？不打不就更安全了……日志信息不全面也能排查问题？那直接不打印 search 参数不就好了。
|
 |
125
Hanggi 2022-01-23 23:43:09 +08:00 1
@caicaiwoshishui 楼主没必要在意楼上这些人胡扯。
听我的，该用什么就用什么。 请求里可以带的东西基本分为 param, query 和 body ，其中 param 和 query 都是写在 url 里的。 如果你觉得你传的参数不应该被直接看到就用 POST 。 其余情况该用什么就用什么。 （例如：GET /v1/articles?page=2&size=20&type=hot 是完全没问题的，也无需担心什么安全问题，真正的安全问题不是 POST 就能解决的，不是吗） 至于你们公司那位，经验告诉我们你没必要舒服他，如果以后有机会写后端你可以使用 Restful API |
 |
126
mogutouer 2022-01-23 23:51:51 +08:00
你如果作为前端，后端接口写好了什么样你直接用就是了，难道你没对接过第三方的接口？比如微信的 API ，微信获取个头像 H5 还在使用跳过去再跳回来加 GET 参数的方式，难道你能去怼腾讯？
|
 |
127
lolizeppelin 2022-01-23 23:55:51 +08:00 1
你要是后端很好解决啊,前端加个 METHOD 重定向就是,全部 post 然后重定向
既解决全 post 问题也解决 restful 问题，没冲突 |
 |
128
3dwelcome 2022-01-24 00:07:25 +08:00 via Android
post 可以携带数据体，get 不能。
如果坚持用 restful ，可以写个转接口，对 get 做向下兼容的。 我个人用 post 挺愉快，以前是 get/post+json ，现在全部用二进制 rpc 传数据，只能单一 post 。流加密后传输，感觉生活真美好。 |
 |
129
kran 2022-01-24 00:24:53 +08:00 via Android
众生百态呀。
数据安全是安全的重要部分 一个系统并不只有业务部分会记录日志 每个部分的数据安全定级不一样。 |
 |
130
relaxgo 2022-01-24 00:30:45 +08:00 1
以前也喜欢 Restful ， 但是实践多了，才发现 post + 方法名作为路径，是最省心的。restful 对于复杂的业务需求，到最后就是四不像，想个路径都是心智负担。安全上最主要就是 get 可能会意外暴露一些信息，但是不是我喜欢 post 主要理由。
|
 |
131
sytnishizuiai 2022-01-24 00:47:14 +08:00 1
@gamexg #101 我跟你相同，所有接口全走 post ，直接封装好一套 jwt 验证机制，我最近 2 年和不同的 4 个前端临时合作，简单把我的调用逻辑讲解 2 分钟，对方就懂了，调通一个接口，剩下接口都没问题。
|
 |
132
2i2Re2PLMaDnghL 2022-01-24 01:45:09 +08:00
啊对对对，不过我觉得 WebSocket 更安全，用 ws 再封装一个 http/1.1 出来吧（
|
|
133
2i2Re2PLMaDnghL 2022-01-24 01:53:50 +08:00
其实也不是非得 RESTful ，更别说你 RESTful 这诡异的大小写都不进行原样模仿，可别无脑捧着吹了。
全用 post 可能是仿 RPC 的形式，甚至可能就是用的 jsonrpc 。 范式（ Paradigm ）都不一样，不存在讨论孰优孰劣的基础。 |
 |
134
hl 2022-01-24 05:14:39 +08:00
国内某大厂核心业务全部为 POST 我说啥了.. POST /api/path?..url params + body 的形式. Header 用于放链路追踪的各种信息，url params 用于接口基本信息上报，body 业务数据
很多时候国内大环境没有所谓的是否遵循协议规范设计，出于种种早期因素演变而来的适合统一协作的规范才是真正的规范。 |
 |
135
RightHand 2022-01-24 07:39:51 +08:00 via Android
都不上 CDN 的吗，全 post 运维不打他？
|
 |
136
Chad0000 2022-01-24 07:48:07 +08:00 via iPhone
@sytnishizuiai #131 我也是全部 post ，就是为了简单然后方便封装。既然 get/post 没有本质区别何必浪费代码呢。
@RightHand #135 目前还没有遇到需要从 http 层缓存 api 的，都是 api 自己读缓存。如果量没有想象中那么大，实际上我觉得直接缓存 api 可能弊大于利。 |
 |
137
murmur 2022-01-24 07:53:15 +08:00
restful 我感觉才是反人类设计
都用 post 好处说不完，唯一的问题就是直接打到浏览器地址框里没法直接访问 |
 |
138
aikilan 2022-01-24 09:02:14 +08:00
技术是过程，业务是目的，别搞得本末倒置了。你的追求可以在你的个人项目里肆意发挥，但是在公司项目上，最好考虑清楚团队之间的合作，你习惯了 restful ，为什么就觉得别人也必须跟着你走？ http 是个协议，restful 只是个协议通讯风格而已。
|
 |
139
aino 2022-01-24 09:12:26 +08:00
对于逆向工程师、安全工程师而已，这都是些笑话
|
 |
140
awanganddong 2022-01-24 09:15:43 +08:00
纯粹的 restful api 不能完美的符合业务侧的需求。
get 和 post 的使用更多的是根据业务来考虑。 全部使用 post 坏处是查操作，以及打日志方面处理起来增加了负担。 好处吗，比如传递参数没有限制。 |
 |
141
FakNoCNName 2022-01-24 09:19:35 +08:00
很早以前大家开发都是 TCP+自定义格式，一把梭哈。http+post 做传输协议，其它格式自定义，两者多类似，什么兼容不兼容的不需要考虑，反正也没其它厂子相互对接。
可能还是那批人，换成 http 以后思路没转换过来，还是按照老思路玩儿的吧。 |
 |
142
cirzear 2022-01-24 09:21:11 +08:00
能用就行
|
 |
143
lbunderway 2022-01-24 09:26:55 +08:00
我们现在是就一个 POST 接口，通过不同业务代码区分{bs_type: 1, data: {}}，感觉也还是不错，而 rest 的确会出现某些业务不好用该原则定义路由，感觉有点怪，
|
 |
144
wenzichel 2022-01-24 09:27:09 +08:00
反驳啥？反驳在 https 下，GET 和 POST 一样安全？还是要反驳他要遵循 restful 规范？
|
 |
145
onionKnight888 2022-01-24 09:28:30 +08:00
全 post 不是问题，全 get 是个问题
|
 |
147
shenqi 2022-01-24 09:50:07 +08:00
graphql 一把梭，自动 post ，不存在这个问题。
|
 |
148
superfatboy 2022-01-24 09:52:31 +08:00
@xianyu191031 写不写的不重要了，我门用 get 请求照样有更新操作，谁管你那个，支持 1 楼
|
 |
149
RainyH2O 2022-01-24 09:52:52 +08:00
没搞明白 POST 更安全的理由，首先 SSL 之上包括 URL 、Header 、Body 都是中间链路透明的。其次不想保留到日志的参数完全应该是设计人员自己的职责。至于 GET 诸如缓存等特性都完全是可控的。
国内大厂觉得自己规范很合理，为啥不起个 fancy 的术语来作为 RestFul 的替代呢？还是说大家其实反的不是 RestFul 而是规范？ |
|
150
superfatboy 2022-01-24 09:53:28 +08:00
@0xsui 你这个是怎么弄得，看起来好厉害的样子
|
 |
151
evill 2022-01-24 09:59:47 +08:00
全 post ？读写分离咋搞？
|
 |
152
wy315700 2022-01-24 10:04:54 +08:00
约定俗成用啥就用啥吧，，争多了其实掉价
比如。 两个马屁股的故事。 比如英尺的来源。 |
 |
153
fengpan567 2022-01-24 10:06:14 +08:00
post 一把梭哈也没什么坏处
|
 |
154
locoz 2022-01-24 10:06:25 +08:00
为什么感觉去年还是前年也看到过同样的帖子...
|
 |
155
quan01994 2022-01-24 10:07:49 +08:00
成年人的世界只有利弊。
|
 |
156
loryyang 2022-01-24 10:07:53 +08:00
至少在我现在的场景里，没什么讲究，随便用
|
 |
157
RedisMasterNode 2022-01-24 10:09:35 +08:00
@evill 因为对他们来说 POST 的语义并不是写操作...他们只把这个方法视为一个 HTTP 的方法之一，完全不考虑语义上的定义..
|
 |
158
liudaolunhuibl 2022-01-24 10:10:51 +08:00
其实 put 、delete 等底层好像都是 post 啊，也没有什么好吵的，只要团队内能对齐就行了，规范的意义在于能够提高沟通、研发效率，如果你发现一个规范不能提高反而会下降那只能说明这个规范不适合你们
|
 |
159
wanguorui123 2022-01-24 10:10:59 +08:00
Post 方便传 JSON 吧
|
 |
160
encro 2022-01-24 10:12:55 +08:00
全 POST 最重要的理由其实是 ----- 方便
1 ，输出文档方便，不用考虑那个参数 GET ，那个 POST 了； 2 ，对接方便，客户端一个函数封装一切接口，服务端取数据也不用思考数据应该从哪里取了； restful 经常遇到的问题： 1 ，查询数据时，需要浏览量加 1 ，这时候对数据有修改，应该用 get 还是 update ，或者要调两个接口？ 2 ，login ，logout 这样的接口，究竟是用 GET,POST,还是 UPDATE 呢？ 3 ，仍然是问题 1 ，第一版本时没有要求浏览量加 1 ，第二版本有要求，需要改 method 吗？ |
 |
161
h1104350235 2022-01-24 10:19:27 +08:00
一楼没啥问题
|
 |
162
NeoZephyr 2022-01-24 10:22:04 +08:00
restful 还是太脆弱了
|
 |
164
phxsuns 2022-01-24 10:32:38 +08:00
全 post 挺好的。后续再也不用沟通 method 了。
前端用起来也方便啊，封装请求方法入参只需要接口地址和入参 json 就好了。 |
|
165
RainyH2O 2022-01-24 10:37:09 +08:00 1
稍微又思考了下，其实 REST 本身也不是规范，而是一种风格。归根结底，只要能抽象成面向资源就 REST ，不能就 RPC 。安全这个就纯属扯淡了。更全面的分析我建议看看周志明大佬的观点： https://icyfenix.cn/architect-perspective/general-architecture/api-style/rest.html 。
|
 |
167
sunus 2022-01-24 10:48:09 +08:00
RESTful 不是规范，只是个风格。风格的东西，团队内部有个共识能执行最重要。无论这个共识是负责人强制规定的，还是大家协商确定的。最怕是每个人各搞一套。
|
 |
168
hardy4y 2022-01-24 11:24:41 +08:00
|
|
169
Hanggi 2022-01-24 12:45:04 +08:00 1
不要再宣扬什么全 POST 没啥问题的这种奇葩言论了。
(这就跟关系型数据不要用 join 一样，你可以这么做，但是不要宣扬这是对的。) 试想，哪天你们公司有机会做一个开放的 API 平台，然后一看文档里面全是 POST 。。。 还有人愿意用吗？随便翻翻国内大厂的 API 开放平台，哪个有全 POST ，不把你直接踢出去。 你一个 HTTP API 接口，既不遵守 Method 也不返回相对应状态码还有理了。 不要给自己的不合规找冠冕堂皇的理由。 请按照规范使用 HTTP Method 和相对应的状态码返回请求值。 |
 |
170
bk201 2022-01-24 12:51:19 +08:00
我觉得不是设计了某个东西，就必须用上。
|
|
171
Chad0000 2022-01-24 13:16:39 +08:00 via iPhone
|
 |
172
xingheng 2022-01-24 13:17:57 +08:00
RESTful 定义的拉屎的地方，他非要在那儿吃饭。为什么要打扰他？
|
 |
173
loading 2022-01-24 13:18:53 +08:00
除了 get 就用 post ，极端点全部用 post 确实省事，以前我也傻看什么 put delete ，不兼容都是瞎扯。
你让我和一个不懂的人说理由，我也会说更安全，说其他的我懒得去解析。 |
 |
174
zalss 2022-01-24 13:49:04 +08:00
他可能只是不想被你卷，他有什么错
|
 |
176
raysonlu 2022-01-24 15:12:07 +08:00
想不到啊，一个简单的问题炸起这么大的讨论。看来经典面试题目“说出你对 get 和 post 请求的理解"还是不能撤掉
|
 |
177
lisongeee 2022-01-24 15:17:20 +08:00
《定义的所有接口都是 post 请求》- 我觉得这很好，甚至还可以直接用 jsonrpc ，因为统一的规范比什么都重要。
《理由是 https 用 post 更安全》- 我觉得 ta 是个傻逼。 |
 |
178
HAYWAEL 2022-01-24 15:28:11 +08:00
@gstqc 根据我的经验。用了 post 之后，就弱化了 method ，都从路径来看，例如 api/getUserName. api/createUserName 。PS：我习惯用 Restful ，但是一些场景 也是自由发挥，因为 restful 在一些场景用 就会不太舒服
|
 |
179
Gota 2022-01-24 15:29:56 +08:00
@shyangs 要不是工作需要, 我碰都不想碰淘宝的坑爹 API.
有些状态码根本对不上, 明明不能重试的错误, sub_code 里写个稍后再试. 还有接口为了偷懒, 返回值里直接找个文本字段, 各种 JSON 字符串往里面塞, 传不同的参数, 这个字段里返回的数据格式都不一样, 全靠自己摸索. 还有各种乱七八糟的情况, 明显是规范覆盖的不全面, 维护接口的几代人各自有各自想法, 越整越乱. |
 |
180
0ZXYDDu796nVCFxq 2022-01-24 15:32:37 +08:00
|
 |
181
liuidetmks 2022-01-24 15:41:41 +08:00
月经贴,总在这些细节上喷来盆去~
|
|
182
Hanggi 2022-01-24 16:01:18 +08:00
|
|
183
HAYWAEL 2022-01-24 16:06:46 +08:00
@gstqc 你没看清我说的。我的意思是 ，全用 post 的人，是不用 method 来区分增删改查，是通过 pathname 的命名来做区分 。
|
 |
184
Dogtler 2022-01-24 22:03:56 +08:00
这不是必然的嘛，现在写接口清一色 post 请求，除非是要分享出去的
|
 |
185
muzuiget 2022-01-25 01:41:41 +08:00
本来第一个帖子的回答就能结贴了。
|
 |
186
afewok 2022-01-25 04:23:22 +08:00 via iPhone
茴香豆有四种写法，即茴、回、囘、囬，它们分别代表不同层次的含义和使用场景，这可是规范和国粹？为啥不好好遵循规范，就只用茴……
|
 |
187
llwwbb7 2022-01-25 10:14:37 +08:00
不太能理解为什么被搜索引擎收录就是不安全
|
 |
188
Quarter 2022-01-26 09:09:42 +08:00 via iPhone
说少沟通成本的，是都从来不写接口文档的，就算不写，也不用 swagger 生成一个，不懂一个请求方式的沟通成本在哪里？这都嫌沟通成本高是怎么对接的业务需求？
至于说安全的，post 又不是为了安全产生的，存在肯定是有存在的意义，不管是不是用 restful ，起码一开始就存在 get 、post 的请求方式， [获取] [邮寄] 按照字面意思也可以区分一下接口，无论从前后端的角度考虑，不然前端请求个列表还得封装个 form-data ，用 json 的话后端是每个接口都写个实体类还是说手动解析一下 json 啊 毕竟技术论坛，多讨论讨论为什么会觉得安全，有哪些好处和坏处，如何优化和沟通，如何提高代码质量什么的… 害，也不知道为啥，莫名的激动，感觉对于这种上来就是反问“……又能怎么样？”“……有什么好处？”极其反感，具体也不多说了 |
|
189
Quarter 2022-01-26 09:16:19 +08:00 via iPhone
@afewok 你觉得是一个意思么，用“茴”是因为是最常见和大众的写法，按照这么理解，为什么不全用 get ，毕竟大部分资源都是 get 获取的，干脆都用 get 好了
|
 |
190
plzcomeon 2022-01-30 10:37:47 +08:00
post 不会记录到 web 服务器日志里面，虽然好像也没啥影响~
|
 |
191
icerwinter 2022-02-13 14:20:53 +08:00
@lanlanye 前后端分离后前端的复杂性导致纯 Restful 请求无法满足。POST 全部，靠谱。
|
 |
192
Imindzzz 2022-02-13 14:28:46 +08:00
都是些无关紧要的优缺点，大家统一规范就行了。
针对楼主我想说，你为什么非要改同事的规范。 如果是项目刚开始，针对同事我想说，http 有一套了你为什么要重新设计。 |
 |
193
shiemi 2022-02-15 17:48:09 +08:00
都用 POST 不是问题，但是都用 POST 还声称自己是 RESTful 就是问题，说 POST 比 GET 安全所以都用 POST 也有问题。内部服务用现有的 rpc 框架比什么都香
|
 |
194
iCong 2022-02-21 15:40:39 +08:00 2
|
 |
195
wupher 2022-03-22 15:11:14 +08:00
又看了一遍，这浓浓的厕所味……
更可悲的是我，之所以又看一遍，新的所谓 ZT 估计又全是 post 。 |
Select Language