你们公司也规定所有接口都用POST吗？聊聊HTTP方法与API设计

最近逛知乎，看到一个讨论度很高的问题：“公司规定所有接口都用 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 认为，如果是他，会按照 『业界最佳实践』 来制定规范：

幂等不修改服务器状态的用GET，幂等修改服务器状态的用PUT，不幂等修改服务器状态的用POST。

而另一位知友 苏莉安 的观点则更为直接和尖锐：

只有一个原因，就是为了迁就低水平不思进取的架构师和前后端程序员们。

跳出技术视角：从ROI看问题

大宽宽 的回答提供了一个更宏观的视角——从投资回报率（ROI）来思考。他认为，任何技术规范（包括 RESTful）的采用，其根本目的是为了在可控成本下让业务落地，而非单纯地“遵守规范”。

对于企业而言，技术团队更重要的职责是理解业务模型、保障系统高可用与高并发、确保数据一致性以及建立有效的监控体系。相比之下，接口具体用 GET 还是 POST，往往只是一个局部问题。

那么，坚持 RESTful 风格到底有哪些明确的好处呢？他列举了几点：

• 清晰的语义：通过 GET/POST/PUT/DELETE 等表达不同的业务动作。
• 资源化概念：利用 URL Path、Query String 等来表达“资源”，形成统一的接口表达形式。
• 工具链支持：这种统一性便于生成和维护接口文档，例如 Swagger。
• 缓存利用：GET 请求的资源可以利用 HTTP 缓存。

但统一的代价又是什么？

有收益就有成本，强行推行一种“最佳实践”可能带来以下问题：

• 抽象过度：将非资源的业务概念强行“资源化”，可能导致理解偏差和沟通成本增加，其收益可能仅限于证明抽象能力和方便使用 Swagger。
• 运维困难：在 Path 或 Query String 中注入变量，会让日志监控、问题排查（比如看到一个404，无法快速定位是服务异常还是资源不存在）变得异常困难。
• 文档冗余：即便使用 Swagger，复杂的业务接口仍需要额外的文档说明，导致开发者需要同时关注两套信息。
• 缓存风险：GET 接口默认可缓存，但对于动态接口，必须额外添加 Cache-Control: no-cache 或动态生成 ETag 来防止用户获取过期数据，增加了复杂度。
• 前端负担：多样的 Method 和 URL 拼接方式，可能要求前端专门封装一个“接口翻译层”，在 Web、iOS、Android 多端开发时，会降低人效。
• 兼容性问题：非 GET/POST 的 Method 可能被某些网关或代理服务器误处理，甚至需要 method override 这样的技巧来规避。

那么，到底什么才是“合适”的？

大宽宽 认为，一个方案是否合适，落地时听听开发团队的“骂声”就知道了。他举了 Google S3 成功运用 RESTful 的例子，但指出 S3 的核心业务就是存取“资源”，这属于完美匹配的场景。这并不能证明电商、社交、医疗等其他复杂业务也适合照搬。

作为技术负责人，衡量标准应该是能否降本增效。 如果他制定的接口规范（即使规定全用 POST）能提升开发效率、降低沟通和运维成本，从而让团队能将更多精力投入到业务架构、测试体系、线上监控等更核心的领域，那这就是一个成功的方案。

反之，如果只是机械地套用书本上的“最佳实践”，导致团队内耗、项目延期，那就是本末倒置。

他分享了自己公司采用的方案，颇具启发性：

对于动态业务接口，我们使用一个统一的入口：POST /action。在 Header 中通过 X-Action 指定具体的业务接口名，由网关负责路由。所有业务参数都以 Protocol Buffers 编码后放在请求体中，直接与后端的 gRPC 体系衔接。这种设计在微服务架构和 后端开发 中能有效提升效率。接口默认不利用 HTTP 缓存，如有需要，可向网关申请配置。而对于静态资源接口，则走 CDN，该用 GET 就用 GET。

总结与思考

这个问题没有标准答案，它深深扎根于具体的团队构成、业务场景和技术发展阶段。

作为开发者或技术决策者，值得我们思考的是：我们当前团队采用的 API设计规范 和 架构设计 ，是当前性价比最高、最适合的选择吗？ 是追求理论上的优雅与规范，还是优先保障团队协作效率与系统稳定？

如果让你来设计公司的 API 规范，你会做出“全部使用 POST”这样的规定吗？背后的原因又是什么？欢迎在 云栈社区 分享你的看法和经历。