公司规定所有接口都用 post 请求，这是为什么？
我曾经也吐过一些槽。比如： 推测一下题主问这个问题，如果不是用来引战创造更多流量经济的情况下，背后想问的是“明明有个更fancy的规范/架构风格“，为啥不用？回答里也不乏“就是为了迁就低水平不思进取的架构师和前后端程序员们“这样的观点。 所以，我打算跳出技术的范畴，从ROI的角度讨论下如果一个架构风格（比如Restful）真的那么好，为啥应用上没有那么广泛？ 首先要明确，不管你多么喜欢技术，无论是这里说的一个http的method，又或者是编程语言的一些用法、架构设计方法、甚至是OKR这样的管理和沟通的方法。这一切，都是为了满足企业对市场的需求。简单来说，公司给你发工资，不是为了让你遵守规范的，而是为了能在成本可接受的情况下，让业务落地。 而其中，一般情况下，接口的形式是个微不足道的局部问题。对于企业来讲，技术团队要解决的更重要的问题，是理解业务模型，形成业务架构和可以稳定跑的系统；是面对大量涌入用户对系统可用性的要求对系统不会卡顿挂机的扩展性保障；是不会动不动抽疯一下，丢条数据或者数据冲突的稳定性要求，以及为了达成这些要求给监控体系的各种便利。 但一定要纠结下POST/GET，以及Restful。好吧，Restful能明确列出来的好处，就那么几点（如果有疏漏的请在评论区里补充）： 但代价是什么？ 所以到底适不适合，落地时听骂声和吵架声就知道了。 有人举了Google S3运用Restful接口的例子来说明其正确性。但S3是干什么的大家都懂，S3天然就是用来存取“资源“的。一个工具用在了恰当场景，当然是”正确“的。S3用的好的东西，只能说明类似的阿里云OSS，腾讯云COS也可以这么干。但无法证明电商业务、社交业务、I医疗业务、政企办公协同……这些业务也适合这么干。 而作为技术负责人，如果他搞出了一套接口方案（也许其中一条就是所有http接口都用post），提高了开发效率，降低了沟通成本，降低了运维和错误定位成本，为企业真正做到了降本增效。把瞎折腾的成本，投入到了其他比如业务架构设计，测试体系，线上监控，容灾降级等领域上。最终让企业（用户需求得到满足，收入增加）和员工得到了收益（因为公司收入增加而涨薪）。我会评价这样的人为“真正懂架构，懂技术，善于用技术解决实际问题。水平不知道高到哪里去了“。 如果一个技术负责人只知道遵守一个书上写的，但从没验证过在自己的环境有效的方案，以至于让企业的核心目标无法达成。他就是赵括，该马上卷铺盖卷走人。 至于我司，使用的规范是。 对于动态业务接口，只有一个接口 POST /action，在Header里给X-Action给出具体的接口名称交给网关路由，session表示用户登录身份，以及用于推荐、防重、染色、安全用到的各种token/签名。所有的业务请求参数都以PB编码后放在请求体里，并和后端的gRPC体系衔接。接口除了防重试之外，不提供常规意义上的Cache。而对于静态接口，走CDN，做多级Cache。该用Get用Get。如果一个动态接口也想利用http层Cache，可以向网关申请和配置。有没有Cache，cache多久是网关和端上自己实施的，完全自己管控。 各位看官可以参考看看，并根据自己所处的业务场景和前后端交互思考下“我们目前用的技术规范是性价比最高的吗，是最合适的吗？“ 另附 