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

[JasonHu]

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

[zhazi]

后端怎么做，是后端的事。
他的接口能按照他的文档正常工作就可以了。
到是你管的挺宽

[warcraft1236]

反对楼上，还是应该遵守通用的规范来

[yuankui]

有副作用用 post，无副作用用 get

[kkshell]

dua 掌噶霖牛了老板

[wysnylc]

说是这么说,等真的严格要求 GET,POST,PUT,DELETE,OPTIONS 又来发帖说后端怎么这么麻烦
呵呵,前端

[mandy0119]

get 调试起来更方便吧。
我现在写项目也不强制控制 get 和 post。
因为非 https 情况下，post 也只是相对于 get，对于用户来说有点保密性，
而且最主要的是，最终请求是以什么类型发出的是前端控制的吧。

[mringg]

post/get 如果从安全性上来说，主要是 csrf 的问题吧

[whoami9894]

@mringg
get 和 post 都可以 csrf，有什么区别吗

[php01]

你们的后端，不合格啊。

[Rekkles]

我司登录态都是前端控制 后端用 session 我还能说啥吗

[Stlin]

我司后端就是 不管是什么请求，都是 post 我 TM 醉了

[wlf92]

不用 delete 和 put 还能理解，post 和 get 不区分一下真是想骂人。

[183387594]

@wlf92global 说的不是不区分 是都支持吧

[maomaomao001]

@Stlin 这个多好

[dongxiaozhuo]

前几天，听一个群友说 UCloud 的所有 API 就是 GET 请求，想起来之前任职过的某个旅游创业公司，我还在的时候后端全是 GET 请求，而且没有区分 path，请求是通过 GET 参数中的 type=u00x 这样来区分的。前端请求个接口必须有个 wiki 做「密码本」来确定这个 00x 到底是做什么的接口。

直到有一天，某个用 Python Web 框架（我忘记是什么） 的后端服务上线，发现部分请求无法正常处理，发现是 uwsgi 和某 Python Web 框架都限制 URL 的长度（包含 query args ），uwsgi 能改配置解决，Web 框架，就只能换一个了。

其实 GET 和 POST 怎么用都行，关键是接口的语义是不是让人能一眼看懂。

[niubee1]

你去看看亚马逊 aws 的文档

[yikyo]

前后端真 TMD 是对立面，不规范还不能评论，反过来喷前端找事。

[garlics]

之前写的接口按语义化区分 post 和 get，结果前端让我前端全部改成 post

[Habyss]

各家有各家的难处,我按照功能和语义来区分不同的请求方式,结果我司前端来一句,你这有的接口不通啊,搞这么多方式干嘛,以前都是一个走天下,现在你搞这么麻烦.关键是我接口文档写得清清楚楚...

[yavin]

不区分，又不是只支持 GET

[Habyss]

之前写的还是 @GetMapping @PostMapping , 现在直接一个 @RequestMapping() ,前端你想用什么用什么....无奈呀

[jun1st]

@Habyss 坚持做正确的事情，然后早点离开 GET POST 无所谓的团队和公司

[Caballarii]

没有人提到 GET 不能（不应该）用 body 吗？虽然没说 GET 一定不能用 body 并且也有很多库支持用 body，但是如今请求转来转去的情况下，保不齐哪一个容器中间件就给你把 GET 的 body 给扔掉了，同理也适用于 DELETE 请求

[semperidem]

因为接口数据内容全得加密，所以只能无脑 POST 的我司🤔

[leonme]

@semperidem get 也能加密啊 手动狗头

[legiorange]

用 struts2 就基本不分。

[semperidem]

@leonme 试过了，发现有些加密后的特殊字符不好处理，总之还是太懒了（狗头） POST 就一把梭完事了

[KuroNekoFan]

不服全干

[karllynn]

get 会把请求参数打印在访问日志里面好伐？你觉得把用户名密码打日志里面合适么

[hoyixi]

没啥大不了的，如果是我，我会偷摸把前端请求库稍稍包装一下下，变成通用的。

下次老板如果说要规范起来， 手吊并举地支持，并煞有其事的开始工作，然后悄悄把请求库开关设置一下，搞定，开始划水~

[abcbuzhiming]

@warcraft1236 少扯淡规范，真要按规范，前端那普遍连类型校验都没有的开发方式是严重的不符合规范。别动不动读了点标准就在那自以为是，流程和规范在真实的实施场景里都是有成本的，视你自己项目和组织的规模大小而定。又不是金科玉律

[abcbuzhiming]

@mringg 不存在，post 和 get 根本不存在所谓的安全问题，你觉得你不把数据放在 get url 上，放在 post 的 requestBody 里就安全了啊？哦，对，如果上 https 的话，requestBody 会加密，那样可以算安全点。就正常来讲，说 post 安全 get 不安全，我就笑笑

[weakish]

@karllynn 如果客户端提交的本来就是加密过的密码的话，可以接受。

[abcbuzhiming]

@yikyo 现在是前端喜欢找事，只要后端没有搞出安全问题，该给的文档给清晰，你管后端一个接口提供 Get 还是 Post，如果说一个接口只提供 Get，或者只提供 Post，那你倒是要问问后端的理由是什么，大部分时候都提供有什么不可以？

[luwies]

一般如果是 post 请求，客户端都不会使用缓存的吧，get 的话就会根据 http 头部信息去使用缓存数据。。。

[httplife]

前提 AJAX 下 , GET 比 POST 好点..

[abcbuzhiming]

@karllynn 这是什么理由，日志里有密码信息你们不会上脱密吗？而且你以为 post 就不打日志了，打 RequestBody 的日志系统又不是没有。

[Lonely]

@yikyo #9 你认为的就是规范吗？

[keepeye]

作为一个后端，站楼主，全 get 真是醉了

[AngelCriss]

不用 http 不就完事了

[karllynn]

@abcbuzhiming 我说的是一般情况呀，你给 ngnix 写个脱密插件不要代价的么。GET 还有缓存问题，当然这些都能解决，但是有必要么…

非要杠的话，我全部用 PUT 也行啊，啧

[Chingim]

所以要对什么是“正确的事”达成共识。

很多东西喷来喷去，就是因为没有共识，这是管理层面的过失，导致员工沟通成本居高不下。

就接口这件事，我认为正确的事是“接口要语义化”，在这个共识下才可以进行更多的讨论。

[lululau]

1. 如果你区分不了 POST/PUT/PATCH，那凭什么要求别人区分 POST/GET ；如果本来就没有要求 API 设计 RESTful，那不区分 POST/GET 就更无可厚非了
2. 如果前后端之间使用 HTTP Header 传递 secret token / session id 之类的，GET 和 POST 都不需要考虑 CSRF 的问题
3. 另外 GET 也可以带 body

[z0ne]

也取决于你前端要怎么传递数据给后端～～
比如你前端用 get 请求登录数据，万一这部分数据被泄漏了（比如日志中）

你说是后端还是前端的问题？ 233

[jaskle]

下载类强制 get，大数据必须 post，其他没啥要求，不过 get 容易被浏览器缓存，还有浏览器自作聪明，主动预读 get

[Anshi]

无所谓 后端大佬怎么要求我怎么做。。。

[fhsan]

写了 3 年 php 才知道有 restful 的路过。

[lzvezr]

get post 无非就是 tcp 连接以后发送的文本文档头部内容，有什么好区分的

[wolfie]

规范规范，GET 还是 POST，事先商量好的才是规范。

[rockyou12]

上面好多说 get 和 post 可以不分的还是闭嘴吧

get 和 post 不区分会有很严重的后果，很多 http 请求框架或者浏览器 get 是会有缓存的，你不分都用 get 的结果就是很多请求成功了但其实没有发送到后端……

[MrJeff]

前端搞一个网关 让后端只提供 RPC 调用 GET POST 就随便你玩了

[iiji86]

想到了这个 https://www.v2ex.com/t/336226

[tabris17]

@rockyou12 并非不能解决，请求加上一次性 token 参数就好了。

GET、POST 语义上的差别甚于行为上的差别。为了语义上的一致性，最好还是要区分开来

[huruwo]

打起来 打起来

[lihongjie0209]

按文档做就好了, 别管那么多

[ipwx]

全都是 POST 的话还可以接受。大不了缓存什么的自己做，说不定还比浏览器好。

全都是 GET，呵呵……

[reus]

GET 和 POST 的区别，在协议层面，就只是第一行有区别
在浏览器层面，可能会对 GET 做缓存，但也会考虑到其他 Header
GET 和 POST 都能带 body，如果你的 GET 是用 body 传数据，那敏感数据应该也不会直接出现在日志里
我个人认为默认 POST 比默认 GET 好一些
当然碰到需要下载文件这类，似乎浏览器只支持 GET
其实，只要后端支持，我 GET、POST 都不用，叫 ASDFGHI 都行，呵呵。

[66beta]

所以说了么，别学前端，做个 crud boy 多好，省心工资又高

[arthas2234]

我一直用着 RESTful 规范，至今还没发现有什么不妥

[luckyx]

restful 规范很重要

[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 那个人了

[tourist2018]

restful api 就行

[eamon666]

我也是醉了 要么就走 restful api 要么就不要墨迹那么多
你们都在纠结啥 呻吟了半天也没个所以然？
get 不能加密？你是弟弟吗？ 对称非对称 明文秘文？签名验证?
要么就说明白点 说明你的理由 到底是自己无知 非要强行 diss 后端
别动不动 醉了 low 了 原地离职 我想请你赶紧快衮 谢谢。

[eamon666]

最后请容我说一句 你写代码的样子像蔡徐坤。

[nodwang]

@iiji86 #52 乐死我了，正坐公交呢，笑出了猪叫

[JamesMackerel]

@jswh 我真希望我能早一年看到你说的这段话。现在回头看自己设计的那些 RPC 的 HTTP API，看到里面又是 GET 又是 POST 还有 DELETE 的，我都想死。鉴权都不好鉴权。

[qwertyyb]

一言难尽。
前段时间接一个项目，get 和 post 全靠猜，json 和 formdata 并存。

下面是举例
登陆接口是 post,但是数据在 params 中传递。
列表获取接口是 post，过滤参数只认 formdata，后端说是框架限制。删除接口是 get，更新添加数据格式又变成 json

最骚的是，返回数据的时候，如果数据为空(空字符串，null, 空数组)，这个字段都没有了，是返回的数据中没有这个字段了！

[abcbuzhiming]

@rockyou12 到底谁该闭嘴啊，学了几个框架就出来教训人，你自己去翻 w3c 标准去，让不让缓存是由服务器决定的，服务器在返回的 http 头里没写让缓存的时候，浏览器凭什么缓存啊？如果现在还有这种不按 w3c 标准实现的浏览器请介绍给我开开眼，你看千万别把 IE6 这样的中古浏览器弄我面前，至于前端框架会按 Http Method 来决定是否缓存？我个人倾向是你根本不会用。我今天真是开眼了，今天居然有人在论坛里叫嚣说 http method 会决定前端是否缓存结果，并且要求别人闭嘴，麻烦去 w3c 标准里找出支持你结论的东西，再来让人闭嘴

[billyma128]

上 GraphQL 就完事了，get -> query，post -> mutation, websocket -> subscription

[billyma128]

@billyma128 post/put/delete -> mutation

[billlee]

有的框架默认就不区分 method.

[hstdt]

@billyma128 我也想说 GraphQL 得了，想要啥数据自己拼

[jiqing]

这种话题肯定会演变出来互喷的。真无聊

[falcon05]

我倾向于区分，经验告诉我们，滥用一时爽，而问题就藏在这些不规范里

[chocotan]

我这儿的网关是不分 post 和 get 的

[rabbbit]

我这边也全走 post,为啥这么作,有什么好处吗?

[muyiluop]

我们有的区分，有的接口不限制，你什么请求方法都行。

[rick2c]

GraphQL+1

[rockyou12]

@abcbuzhiming 我只提了浏览器？ http 请求只能浏览器来做？而且 http client 默认缓存 get 请求我又不是没遇到过，你可以说整个 http client 实现又问题，但现实就是有这种烂货，而且你要提 w3c 标准，自己翻下 w3c 的标准再喷好不，不晓得你是逻辑混乱智商出现问题还是单纯的学艺不精

https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.1.1 Safe Methods

......

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

......

[rockyou12]

@abcbuzhiming 我标准也给了，有诚意自己道个歉吧

[jyf]

我比较喜欢全 post 主要是把 http 当作一个隧道来看 不想依赖他的特性 因为随时可能切到 ws 或者其他协议上去