为啥现在越来越多公司接口都使用post 而不用 get

问题（场景）

最近在开发一个新项目，开了一个项目启动大会，前端的同事提出交互都用 post 请求,而且都是用Restful的风格。
我提出了一些不一样的意见

简单介绍一下 post、get 和 Restful

GET：字面理解就是获取资源

GET请求标准上是幂等的（用户应该认为请求是安全的-资源不会被修改，这里所以说应该是服务器端并不保证资源不会被修改）
GET请求可以被浏览器缓存；响应也可以被缓存（根据缓存头信息来处理）
GET请求可以保存在浏览器历史记录中，也可以作为链接分发或分享，可以收藏为书签
GET请求的数据都在URL中，可以方便都从浏览器中获取数据（因此不能携带诸如密码的明文数据）
GET请求的长度会有限制（比如IE的路径总长度需小于2048个字符）
GET请求的数据只能包含ASCII字符

POST：字面理解就是发布新资源

POST请求标准上不是幂等的（用户应该认为请求是有副作用的-可能会导致资源修改）
POST请求URL可以被浏览器缓存，但是POST数据不会被缓存；响应可以被缓存（根据缓存头信息来处理）
POST请求不便于分发或分享，因为POST数据会丢失，不能收藏为书签。
POST请求没有长度限制，可以用来处理“请求数据”很大的场景（只要不超过服务器端的处理能力）
POST请求的数据不限于ASCII字符，可以包含二进制数据

Restful

    Restful就不做过多的介绍了，不了解的同学可以在直接搜一下就可以了  **http://restful.p2hp.com/search**
    我们来简单了解一下 Restful的优缺点：
Restful能明确列出来的好处，就那么几点（如果有疏漏的请在评论区里补充）：
    1 表达不同的业务动作语义：GET/POST/PATCH/PUT/DELETE……，
    2 表达“资源”的概念利用
    3 url path，querystring，header，status code等来表达很多接口功能
    4 以上两条可以达成一种“统一”的接口表达形式，以至于可以围绕这个形式实现接口维护的工具，比如swagger。
    5 Get资源可以利用缓存
但代价是什么
    1 强行的统一，让本来天然不是资源的业务概念也一定要强行“资源“一下，引发了更多的理解不一致和沟通困难。当然，事物总是和可以“抽象”一下，业务概念抽象为“资源”很多时候都是可行的。但这这么做的收益除了证明“一个人聪明，有不错的抽象能力“，以及“更容易利用上swagger一类的工具“之外，我看不到啥额外的短期或者长期收益。
    2 乱折腾path，querysting等东西，让横切面治理抓取关键信息更难了。比如监控时抓一个path里带变量的url是非常恶心的事情。又或者看到一个404的报警，却根本搞不清楚到底是服务部署有问题；还是服务正常，但用户不存在；又或者是用户存在，但用户订单不存在。带来的问题是运营工具编写困难，线上问题响应能力会被降低。
    3  即使使用swagger，还是需要写说明和文档来说明其业务语义。接口工具应该提供的“好理解，接口改了后文档自动生成”等好处，只有在接口反应的资源刚好和后台数据表/视图能够对应上才有效。也就是说只适合接口层级低的场景下有用，而对高层接口意义不大。结果开发者既要用swagger这样的工具，同时还是要看常规文档。本来用一套机制可以解决的问题要改成两套。
    4 Cache虽好，但最怕的是管控不到位让用户拿到了过期数据。对于Cache，业务上一般会区分动态接口和静态接口。前者默认不应该有cache，所以用了Get之后为了防范，还得手工在大部分动态接口上加Cache-Control: no-cache，或者动态产生ETag（浪费CPU）。而后者一般会采用CDN，这一套针对cache做了很精巧的设计。
    5 使用形式各异的method和url path，querystring上做各种奇怪的拼接，会给前端带来巨大的困扰，因为本来一个函数调用，还得翻译一遍，活生生的弄出来一个接口翻译层。妥妥的降低人效。如果是web，iOS，Android三套前端，就得弄3个接口翻译层。
    6 非GET和POST之外的method有可能会被不恰当的网关转发规则给干掉。为此Restful还是搞出了method override这样的招数……

思路扩展

如果大家设计自己公司的api规范，会怎么设计呢？为什么这么设计？大家想明白了吗？

结论

    如果他搞出了一套接口方案（也许其中一条就是所有http接口都用post），提高了开发效率，降低了沟通成本，降低了运维和错误定位成本，为企业真正做到了降本增效。把瞎折腾的成本，投入到了其他比如业务架构设计，测试体系，线上监控，容灾降级等领域上。最终让企业（用户需求得到满足，收入增加）和员工得到了收益（因为公司收入增加而涨薪）
那这样确实挺好的，
    但是如果说只是按照书上写得，不结合实际的情况的话，那就是纸上谈兵了，大家设计东西的时候一定要结合实际情况。
    一般的规则是：幂等不修改服务器状态的就用get，不幂等修改服务器状态用post，幂等修改服务器状态用put。
    

留个关注

《日常分享系列》，会持续更新，想了解的朋友可以关注 ，文章有帮助的话可以长按点赞有惊喜！！！文章比较长，大家可以先 收藏、转发后再看，有什么补充可以在下面评论，谢谢大家！