技术规范之争：为什么有些公司规定所有接口都用POST？

最近在逛知乎时，我发现了一个挺有趣的技术讨论：《公司规定所有接口都用 post 请求，这是为什么？》。

原问题地址：zhihu.com/question/336797348

看到这个问题时我其实挺有感触的，因为我也曾这样问过自己。在我上上一家公司，接手一个从零开始搭建的微服务项目时，就研究过各种接口规范，当时耳熟能详的RESTful规范就被应用到了这个项目中。

今天再次看到这个问题，我有了些新的理解，也临时回顾了一下 GET 与 POST 请求的一些核心区别：

1. POST更安全（数据不会作为URL的一部分，不会被缓存、保存在服务器日志或浏览器历史记录中）
2. POST可发送更大数据量（GET有URL长度限制）
3. POST支持更多数据类型（GET只能发送ASCII字符）
4. POST通常比GET慢
5. POST常用于修改和写入数据，GET一般用于搜索、排序和筛选等操作
6. GET请求若指向静态资源则会缓存，如果是数据则通常不缓存

查看上述区别，你会发现POST在发送大数据量请求时优势明显，而GET则更适合获取静态资源或进行简单查询。

我个人在开发接口时也会注意区分：简单的查询用GET，增、删、改及复杂查询用POST。但不会像问题中描述的公司那样，规定全部使用POST。

来自知友的观点

网友程墨 Morgan 提出，如果是他自己，会按照「业界最佳实践」来制定规范。

另一位知友苏莉安 则直言不讳地指出，这可能“就是为了迁就低水平不思进取的架构师和前后端程序员们”。

大宽宽 的回答则从更务实的ROI（投资回报率）角度进行了分析：

我打算跳出纯粹的技术范畴，从ROI的角度讨论一下：如果一个架构风格（比如RESTful）真的那么好，为什么在实际应用中没那么广泛？

首先要明确一点，不管我们多喜欢某项技术，无论是HTTP方法、编程范式、架构设计还是管理方法，这一切的最终目的都是为了满足业务需求、帮助企业成功。公司支付薪水，核心目的是在可控成本下让业务稳定落地，而不仅仅是让团队遵守某种技术规范。

通常情况下，接口的具体形式只是一个局部问题。对企业而言，技术团队更需要解决的是：理解业务模型、构建稳定的系统架构；保障系统在高并发下的可用性与扩展性；确保数据的准确性与系统稳定性；以及建立完善的监控体系。

但如果一定要纠结POST/GET以及RESTful，我们可以罗列一下RESTful明确的好处（如有疏漏欢迎补充）：

• 表达不同的业务动作语义：通过GET/POST/PATCH/PUT/DELETE等方法区分操作。
• 强化“资源”概念：利用URL路径来表达资源。
• 统一接口表达形式：综合使用URL path、querystring、header、status code等来传达接口信息，这种统一性便于生成像Swagger这样的接口文档工具。
• 利用缓存：GET请求的资源可以被缓存。

但代价是什么？

• 过度抽象带来理解成本：强行将一切业务概念统一为“资源”，可能导致理解不一致和沟通困难。这种抽象的收益，除了证明设计者的抽象能力外，短期或长期的业务收益并不明显。
• 增加运维监控难度：在path、querystring上做复杂拼接，会让日志监控、问题排查变得困难。例如，监控一个路径中带变量的URL是非常棘手的事情；看到一个404报警，很难快速区分是服务部署问题、用户不存在还是资源不存在。
• 文档维护并未简化：即使使用Swagger，仍然需要额外的文档来说明业务语义。其“好理解、自动同步”的优势，往往只在接口与底层数据模型高度对应时才成立。结果可能是开发者既要用Swagger，又要看传统文档，维护成本反而增加。
• 缓存管理复杂度上升：缓存用得好是优势，管理不当则是灾难。业务接口通常需区分动态与静态，动态接口默认不应缓存。使用GET后，为防缓存，不得不在大部分动态接口上手动添加Cache-Control: no-cache或动态生成ETag（消耗CPU）。而静态资源缓存，现代CDN已经有非常成熟的设计。
• 增加前端开发负担：形式各异的HTTP Method和URL构造，会给前端带来额外工作，需要专门一个“接口翻译层”来适配，如果同时有Web、iOS、Android多端，则成本成倍增加。
• 可能存在基础设施兼容性问题：一些旧的网关、代理或防火墙可能无法正确识别或转发PUT、DELETE等非GET/POST的HTTP方法，为此甚至需要引入method override这样的变通方案。

那么，什么才是合适的？

实践是检验真理的唯一标准，一个方案是否合适，听听落地时的“骂声”和讨论声就知道了。

有人举出Google S3成功运用RESTful接口的例子。但S3是云存储服务，其核心就是存取“资源”，这恰恰是RESTful理念最匹配的场景。一个工具用在恰当的地方当然是正确的，但这并不能证明电商、社交、医疗、协同办公等所有复杂业务系统都适合照搬。

作为一名技术负责人，如果他制定了一套接口方案（也许就包括“所有接口都用POST”），最终切实提升了开发效率、降低了沟通与运维成本，为企业做到了降本增效，并把省下的精力投入到业务架构、测试体系、线上监控等更核心的领域，从而让企业和员工都受益。那么我会评价这样的人为：“真正懂架构，懂技术，善于用技术解决实际问题。”

反之，如果一个技术负责人只会机械照搬书本上的“最佳实践”，而不考虑其在自身业务环境下的有效性，甚至因此阻碍了核心业务目标的达成，那他就是现代的“赵括”。

以我司为例，我们采用的规范是：对于动态业务接口，统一使用 POST /action，在Header中通过X-Action指定具体的业务操作，由网关进行路由。所有业务参数都通过Protobuf编码后放在请求体中，与后端的gRPC体系无缝衔接。这类接口默认不提供HTTP层缓存。对于静态资源，则走CDN，该用GET就用GET。如果某个动态接口确有缓存需求，可以向网关申请并配置，缓存策略完全自主管控。

总结与思考

技术规范的选择，从来不是非黑即白的“对错”问题，而是关乎“合适”与“权衡”。作为一名后端开发者，我们在讨论此类问题时，不妨跳出技术细节，从团队协作效率、业务复杂度和长期维护成本等更宏观的维度来思考。

那么，如果是你来设计公司的API规范，你会做出怎样的选择？是严格遵循RESTful，还是采用更务实的统一POST方案？欢迎在技术社区交流你的看法。例如，你可以在云栈社区的相关板块找到更多关于系统设计、网络协议的深度讨论。