文章来源：http://suo.nz/1vdmri背景
get 与 post 的区别
所有接口都用 post 请求？
最近在逛知乎的时候发现一个有趣的问题：公司规定所有接口都用 post 请求，这是为什么？看到这个问题的时候其实我也挺有感触的，因为我也曾经这样问过我自己。在上上一家公司的时候接到一个项目是从零开始搭建一个微服务，当时就有了解过接口的一些规范，比如耳熟能详的 Restful 规范，就被应用到这个微服务项目中。今天再次看到这个问题，我也有了一些新的理解和感触，临时回顾了一下 get 与 post 的请求的一些区别。- post 更安全（不会作为 url 的一部分，不会被缓存、保存在服务器日志、以及浏览器浏览记录中）
- post 发送的数据更大（get 有 url 长度限制）
- post 能发送更多的数据类型（get 只能发送 ASCII 字符）
- post 用于修改和写入数据，get 一般用于搜索排序和筛选之类的操作
- get 请求的是静态资源，则会缓存，如果是数据，则不会缓存
查看上面的区别，就会发现 post 在发送数据量大的请求时优势很显示，get 则更适合获取静态资源、简单的查询等接口。我个人在开发接口的时候也会注意，将简单的查询请求使用 get 方法，其他增、删、改、复杂的查询请求都可以使用 post，但不会像题主的公司一样全部使用 post。| 网友程墨 Morgan
网友程墨 Morgan 提出如果是自己会按照『业界最佳实践』制定规范：| 网友苏莉安
另外一个知友提出：就是为了迁就低水平不思进取的架构师和前后端程序员们。| 网友大宽宽
大宽宽的回答：我打算跳出技术的范畴，从 ROI 的角度讨论下如果一个架构风格（比如 Restful）真的那么好，为啥应用上没有那么广泛？首先要明确，不管你多么喜欢技术，无论是这里说的一个 http 的 method，又或者是编程语言的一些用法、架构设计方法、甚至是 OKR 这样的管理和沟通的方法。这一切，都是为了满足企业对市场的需求。简单来说，公司给你发工资，不是为了让你遵守规范的，而是为了能在成本可接受的情况下，让业务落地。而其中，一般情况下，接口的形式是个微不足道的局部问题。但一定要纠结下 POST/GET，以及 Restful。好吧，Restful 能明确列出来的好处，就那么几点（如果有疏漏的请在评论区里补充）。- 表达不同的业务动作语义：GET/POST/PATCH/PUT/DELETE……，
- url path，querystring，header，status code 等来表达很多接口功能
- 以上两条可以达成一种“统一”的接口表达形式，以至于可以围绕这个形式实现接口维护的工具，比如 swagger。
①强行的统一，让本来天然不是资源的业务概念也一定要强行“资源“一下，引发了更多的理解不一致和沟通困难。当然，事物总是和可以“抽象”一下，业务概念抽象为“资源”很多时候都是可行的。但这这么做的收益除了证明“一个人聪明，有不错的抽象能力“，以及“更容易利用上 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 这样的招数……有人举了 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 多久是网关和端上自己实施的，完全自己管控。各位读者可以参考看看，并根据自己所处的业务场景和前后端交互思考下“我们目前用的技术规范是性价比最高的吗，是最合适的吗？“如果是你来设计公司的 API 规范，会规定所有接口都用 post 请求吗，这是为什么？
