技术日常系列为什么现在都是用post请求，不让用get请求

　　为啥现在越来越多公司接口都使用post 而不用 get问题（场景）
　　最近在开发一个新项目，开了一个项目启动大会，前端的同事提出交互都用 post 请求,而且都是用Restful的风格。
　　我提出了一些不一样的意见简单介绍一下 post、get 和 RestfulGET：字面理解就是获取资源    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。
　　留个关注
　　《日常分享系列》 ，会持续更新，想了解的朋友可以关注  ，文章有帮助的话可以长按点赞 有惊喜！！！文章比较长，大家可以先 收藏 、转发 后再看，有什么补充可以在下面评论 ，谢谢大家！