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

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

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

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

dua 掌噶霖牛了老板

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

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

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

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

你们的后端，不合格啊。

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

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

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

@Stlin 这个多好

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

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

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

你去看看亚马逊 aws 的文档

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

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

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

不区分，又不是只支持 GET