突发！公司规定所有接口都用POST请求

小二刚去一家公司实习俩月，就收到一则震惊了他双眼的通知：“公司规定所有接口都用 POST请求！”他非常不解，跑来问我。

我说：因为需要防止低级 bug 的出现以及初级开发人员的自尊心。

小二将信将疑，我又说：讲真，我菜鸟时期，一般是这样认为的。

• 传参内容少的就用 GET
• 传参内容多的就用 POST

关键是，我感觉自己特别的专业，你知道吗？

直到我用 GET 传参的时候出现了一些低级 BUG，比如说 URL 被缓存，导致重复下单。

用 POST 就可以轻而易举地避免 URL 缓存。

按照「业界最佳实践」的制定规范：幂等不修改服务器状态的用 GET，幂等修改服务器状态的用 PUT，不幂等修改服务器状态的用 POST。

可有的时候，规范就会造成干扰：幂等是什么？服务器状态是什么？

对！

说了你又不听

听了你又不懂

懂了你又不做

做了你又做错

错了你又不认

认了你又不改

改了你又不服

不服你又不说

那为了不出错，简单粗暴的 POST 就是最佳的解决方案。

拥抱 POST 吧，头发很宝贵的。

小二听我这么一说，还是不放心，我把上次面试官：GET 和 POST 到底有什么区别？的文章就甩给了他，要他好好看看。

小二看完后，又追着我继续问：Restful真的那么好，为啥应用上没有那么广泛？

我就把大宽宽答主的另外一个回答扔给了他，以下是部分内容。

编辑：沉默王二，链接：https://www.zhihu.com/question/336797348

首先要明确，不管你多么喜欢技术，无论是这里说的一个http的method，又或者是编程语言的一些用法、架构设计方法、甚至是OKR这样的管理和沟通的方法。这一切，都是为了满足企业对市场的需求。

简单来说，公司给你发工资，不是为了让你遵守规范的，而是为了能在成本可接受的情况下，让业务落地。

而其中，一般情况下，接口的形式是个微不足道的局部问题。对于企业来讲，技术团队要解决的更重要的问题，是理解业务模型，形成业务架构和可以稳定跑的系统；是面对大量涌入用户对系统可用性的要求对系统不会卡顿挂机的扩展性保障；是不会动不动抽疯一下，丢条数据或者数据冲突的稳定性要求，以及为了达成这些要求给监控体系的各种便利。

但一定要纠结下POST/GET，以及Restful。好吧，Restful能明确列出来的好处，就那么几点：

• 表达不同的业务动作语义：GET/POST/PATCH/PUT/DELETE……，
• 表达“资源”的概念
• 利用url path，querystring，header，status code等来表达很多接口功能
• 以上两条可以达成一种“统一”的接口表达形式，以至于可以围绕这个形式实现接口维护的工具，比如swagger。
• Get资源可以利用缓存

但代价是什么？

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

所以到底适不适合，落地时听骂声和吵架声就知道了。

作为技术负责人，如果他搞出了一套接口方案（也许其中一条就是所有http接口都用post），提高了开发效率，降低了沟通成本，降低了运维和错误定位成本，为企业真正做到了降本增效。

把瞎折腾的成本，投入到了其他比如业务架构设计，测试体系，线上监控，容灾降级等领域上。最终让企业（用户需求得到满足，收入增加）和员工得到了收益（因为公司收入增加而涨薪）。

我会评价这样的人为“真正懂架构，懂技术，善于用技术解决实际问题。水平不知道高到哪里去了“。

如果一个技术负责人只知道遵守一个书上写的，但从没验证过在自己的环境有效的方案，以至于让企业的核心目标无法达成。他就是赵括，该马上卷铺盖卷走人。

至于我司，使用的规范是。

对于动态业务接口，只有一个接口 POST /action，在Header里给X-Action给出具体的接口名称交给网关路由，session表示用户登录身份，以及用于推荐、防重、染色、安全用到的各种token/签名。

所有的业务请求参数都以PB编码后放在请求体里，并和后端的gRPC体系衔接。接口除了防重试之外，不提供常规意义上的Cache。而对于静态接口，走CDN，做多级Cache。

该用Get用Get。如果一个动态接口也想利用http层Cache，可以向网关申请和配置。有没有Cache，cache多久是网关和端上自己实施的，完全自己管控。

小二看完这个帖子后，长长地“哦”了一声，我明白他是真的懂了，为什么公司规定所有接口都用 POST请求了！

没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。