最近逛知乎发现了一个很有意思的问题：《公司规定所有接口都用 post 请求，这是为什么？》看到这个问题的时候其实挺感动的，因为我也问过自己这个问题。在上一家公司的时候接到了一个项目，要从零开始搭建一个微服务。当时知道接口的一些规范，比如大家熟悉的Restful规范，就应用到了这个微服务项目中。今天又看到这个问题，也有了一些新的理解和感受。暂时回顾一下get和post请求的一些区别：post更安全（不会作为url的一部分，不会被缓存，不会保存在服务器日志，浏览器浏览记录中）发送的数据bypost较大（get有url长度限制）post可以发送更多的数据类型（get只能发送ASCII字符）post比get慢post用于修改和写入数据，get一般用于搜索等操作，排序和过滤。get请求是静态资源，会被缓存。如果是数据，则不会缓存。看了上面的区别，你会发现post在发送大数据量的请求时有很大的优势。可见get更适合获取静态资源、简单查询等接口。我个人在开发接口的时候也比较注意，简单的查询请求使用get方法，其他的增删改查，复杂的查询请求使用post，但是不会像题主的公司一样全部使用post。网友程墨摩根提出，如果是他，他会按照“行业最佳实践”来制定规范：程墨摩根的另一位朋友建议，这是为了容纳底层架构师和前后端程序员没有进取心。有朋友回答大宽宽：我打算跳出技术范畴，从ROI的角度来讨论。如果一种架构风格（比如Restful）真的那么好，为什么没有那么广泛的应用呢？首先要明确的是，不管你有多喜欢技术，不管是这里说的http方式，还是编程语言的一些用法，架构设计方式，甚至是OKR这样的管理沟通方式。这一切都是为了满足市场上企业的需求。简单来说，公司付钱给你，不是让你遵守规定，而是让企业以可接受的成本落地。其中，一般情况下，界面的形式是一个微不足道的局部问题。对于企业来说，技术团队更需要解决的问题是理解业务模型，形成业务架构和能够稳定运行的系统；就是要面对大量用户对系统可用性的要求，系统不会挂掉。可扩展性保证；就是不发疯、不丢数据、不数据冲突的稳定性需求，以及监控系统为了满足这些需求而提供的各种便利。但是一定要纠结POST/GET，和Restful。好吧，Restful能明确列出的好处就这么几点（如有遗漏请在评论区补充）：表达不同的业务动作语义：GET/POST/PATCH/PUT/DELETE...，表达“资源”概念使用url路径、querystring、header、状态码等来表达很多接口功能。以上两者可以实现一种“统一”的接口表达形式，从而可以围绕这种形式实现接口维护的工具，比如swagger。获取资源可以利用缓存，但代价是什么？强行统一使得本来不是自然资源的商业概念也必须强行成为“资源”，从而导致更多的理解不一致和沟通困难。当然，事物总是可以“抽象”的，将业务概念抽象为“资源”往往是可行的。但除了证明“一个人聪明，抽象能力好”，“用swagger这样的工具更容易”之外，我看不到任何额外的短期或长期利益。折腾path、querysting等，让横截面管理更难抓取关键信息。比如在监控的时候抓取一个路径中有变量的url，是非常恶心的。或者你可能看到404告警，但不清楚是不是服务部署有问题；或者服务正常，但用户不存在；或用户存在，但用户订单不存在。问题是运维工具很难写，对线上问题的响应能力会降低。即使有swagger，你仍然需要编写说明和文档来解释它的业务语义。界面工具应该提供“简单易懂，界面变化后自动生成文档”等好处，只有界面反映的资源刚好对应后台数据表/视图才有效。也就是说只适用于底层接口场景，对于高层接口意义不大。这样一来，开发者不仅需要使用swagger等工具，还需要阅读正规的文档。本来可以用一种机制解决的问题应该改为两种。Cache虽然好，但最怕的就是缺乏控制让用户拿到过期的数据。对于Cache，业务上一般会区分动态接口和静态接口。前者默认应该是没有缓存的，所以为了防止在使用Get之后，大部分动态接口都得手动加上Cache-Control:no-cache，或者动态生成ETag（浪费CPU）。后者一般使用CDN，这套对缓存的设计非常精巧。使用不同的方法和url路径，对querystring进行各种奇奇怪怪的拼接，会给前端带来巨大的麻烦，因为本来一个函数调用要重新翻译，活生生的创建了一个接口翻译层。适当降低人的效率。如果是web、iOS、Android三个前端，就得弄三个接口翻译层。GET和POST以外的方法可能会被不合适的网关转发规则杀死。为此，Restful还是想出了methodoverride之类的tricks……所以适不适合，落地的时候听到骂声和吵架声就知道了。有人举了GoogleS3使用Restful接口的例子来说明其正确性。但是每个人都知道S3是做什么的。S3自然是用来访问“资源”的。在正确的情况下使用的工具当然是“正确的”。S3用的好东西只能说明类似阿里云OSS，腾讯云COS也能做到。但是，无法证明电商业务、社交业务、I医疗业务、政企办公协同……这些业务也适合做这个。作为技术负责人，如果自己想出一套接口方案（可能其中之一就是对所有http接口都使用post），会提高开发效率，降低沟通成本，降低运维和错误定位成本，为企业提供实实在在的效益。实现了降本增效。折腾折腾的成本投入到业务架构设计、测试系统、在线监控、容灾降级等其他领域。最终是企业（用户需求得到满足，收入增加）和员工受益（公司收入增加导致工资增加）。我会给这样的人评价“真正懂架构，懂技术，善于用技术解决实际问题，不知道水平有多高”。如果一个技术leader只知道照本宣科，却从来没有验证过在自己的环境下有效的解决方案，那么公司的核心目标就无法实现。他是赵括，应该马上收拾东西离开。至于我们公司，使用的规格是。对于动态业务接口，只有一个接口POST/action，具体的接口名称交给Header中的X-Action进行网关路由。各种令牌/签名。所有业务请求参数都用PB编码放在请求体中，与后端gRPC系统对接。除了防重试之外，该接口并没有提供常规意义上的Cache。对于静态接口，使用CDN，使用多级缓存。使用Get来使用Get。如果动态接口也想使用http层Cache，可以向网关申请并配置。是否有缓存，缓存多长时间由网关和终端实现，完全由自己控制。读者可以参考，根据自己的业务场景和前后端交互思考，“我们目前使用的技术规范是不是性价比最高的，是不是最合适的？”如果你设计公司的API规范，会不会规定所有接口都使用post请求，为什么？原题：zhihu.com/question/336797348
