总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 zhihu.com/question/336797348 「网络」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

最近在逛知乎的时候发现一个有趣的问题：《公司规定所有接口都用 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 提出如果是自己会按照『业界最佳实践』制定规范：

程墨 Morgan

另外一个知友提出：就是为了迁就低水平不思进取的架构师和前后端程序员们。

知友回答

大宽宽的回答：

我打算跳出技术的范畴，从 ROI 的角度讨论下如果一个架构风格（比如 Restful）真的那么好，为啥应用上没有那么广泛？

首先要明确，不管你多么喜欢技术，无论是这里说的一个 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这样的招数……

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

有人举了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 请求吗，这是为什么？

文章目录