共计 2931 个字符，预计需要花费 8 分钟才能阅读完成。
最近在逛知乎的时候发现一个乏味的问题：《公司规定所有接口都用 post 申请，这是为什么？》
看到这个问题的时候其实我也挺有感触的，因为我也已经这样问过我本人。在上上一家公司的时候接到一个我的项目是从零开始搭建一个微服务，过后就有理解过接口的一些标准，比方耳熟能详的 Restful 标准，就被利用到这个微服务项目中。
明天再次看到这个问题，我也有了一些新的了解和感触，长期回顾了一下 get 与 post 的申请的一些区别：
- post 更平安（不会作为 url 的一部分，不会被缓存、保留在服务器日志、以及浏览器浏览记录中）
- post 发送的数据更大（get 有 url 长度限度）
- post 能发送更多的数据类型（get 只能发送 ASCII 字符）
- post 比 get 慢
- 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。
- 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 申请吗，这是为什么？
原问题：zhihu.com/question/336797348
