后端写的接口不区分 get 跟 post 是什么感受？

[JasonHu]

作为一个前端切图仔而言，所有请求全部用 get 都可以跑通。包括登录

[yzkcy]

@whoami9894 post csrf 和 get csrf 的利用难度和危害级别方面还是有区别的。另外也会有 CDN/缓存 /请求日志等东西记录 /缓存 get 请求，可能会泄漏其中的帐号密码等敏感信息。

[Beeethoven]

公司约定 GET 不能带 BODY 所以 GET/POST 判断起来很轻松

[doublleft]

@yuankui 从头看到尾，只有你把区别说道点子上了。副作用、幂等

[tabris17]

@yzkcy 头部加上 Cache-control: private

[Yiki]

你可以和公司提规范啊
暗戳戳说是没有用的

[otakustay]

GET 最大的问题是搜索引擎会爬和浏览器会预加载，看看 chrome://predictors 就懂

[JRay]

我就记得之前老大说，尽量不要用 get，全部 post 就完事

[wangxiaoaer]

@zhazi #1 洗什么洗？这明显是后端二把刀水平的事情。

现在流行怼人为乐了吗？

当后端说前端不懂 Restful 的时候，你们说前端不够专业。

当前端说后端不区分 post 的时候，你们说前端多管闲事。

[jswh]

RPC 类型的 API，有时候确实不分 get/post，有时候只能 post，有时候甚至支持 get/post 混用，有时候只能 websocket。完全看设计接口框架的人的看法。有的 RPC 觉得反正你把参数给我就行了，我不管那么多，我不关系 http 规范，只把 http 当作一种数据传输协议用。
只有 RESTful 类型的 API，才一定会强调说 get/post，因为它要依赖 http 动词来判断动作。

[jswh]

@jswh 上面的举个例子，LDAP 完全是自己的一套协议，但是也可以走 http 实现。

[jswh]

@jswh 另外，完全不区分 get/post，在一些七层路由服务里可能会有问题，比如客户端的 get 请求里面带了 body，但是一般 get 请求没有 body，七层路由转发的时候就不处理了。而且 get 的参数长度限制不一，所以 RPC 类型的 API 还是用 post 比较多。

[jswh]

总之这完全不是能不能的问题，完全就是个设计风格和品味的事情。但唯一确定的是，单一项目内部这个风格和品味需要统一。

[sirm2z]

戾气真重

[yikyo]

@Lonely restful 是我认为的规范吗？

[MeteorCat]

.......我又是也开 get/post 共用，为了开发服务器能够看到 nginx 的参数日志调试

[zhazi]

@wangxiaoaer
第一，我没说
第二，别说的这么业余，post 只有一种不需要区分，需要区分的是 http methods
既然你想杠，咱就在这扯会
Restful 从来就不是什么强制执行的规范，而是一种风格。具体实现要靠前后端协商。
另外 Http 是一种通讯协议，也不是强制规定，如果你想使用这个协议，那么他会给你提供一系列解决方案。如果觉得他的方案不适合你们的项目，那么你们可以自己实现。
那么问题来了，
后端给出接口文档（这就指定了他的接口需要遵从这个规范）
你想接入这个接口。就要这么用有，请问有什么问题？
如果你对上面这句话不理解的话，那你估计跟第三方接口对接的也是很不愉快。
你的工作是做好自己的工作，而不是告诉后端如何实现。

[SunoAries]

乖乖，rpc 全是 post，日常想离职

[ikkknlm]

前端管得挺宽的

[starsriver]

说不定后台只用 request 函数，过滤请求了也说不定

[CX]

这都能打起来，怪不得啥要大统一，突然有点怀念 apijson 那个人了