因为懒，但懒得很有道理

说起 RESTful 接口设计，教科书里的理论讲得很漂亮：GET 获取资源、POST 创建资源、PUT 更新资源、DELETE 删除资源，URL 写成  /users/123  这种形式，一眼就能看出是操作编号123的用户。优雅标准，面试也很适合拿来侃侃而谈。

可落到真实业务开发就会发现，严格照搬这套规范写代码，实在太折磨人。

RESTful 在实际业务里的尴尬，举几个常见接口场景就能体会：

- 用户登录

- 批量删除订单

- 查询用户近30天消费统计

- 将购物车商品移动到收藏夹

你来想想，这几个接口该选什么HTTP方法？URL又该如何设计？

登录用 GET 还是 POST？难道要把密码拼接在URL里？

批量删除用 DELETE？那大批量ID参数往哪里放？

消费统计走 GET？查询条件一多，URL长度直接爆炸。

把购物车商品移入收藏夹又属于什么操作？PUT、PATCH 还是 POST？

硬套 RESTful，你大部分时间不是在写业务逻辑，而是在和规范较劲。

现实业务远不止简单的增删改查，大量接口本质是执行某一个动作，并不完全适配 RESTful 面向资源的设计思路。

于是很多团队选择全部接口统一用 POST。

图的是什么？就是省心。

全部接口采用 POST + JSON 请求体，开发阶段不用反复纠结这个接口该选哪种HTTP方法，前端也不用记忆哪些接口用GET、哪些用POST，整套体系保持高度统一。

别小看这点，团队规模变大之后，规范统一，远比理论上的规范正确更加重要。

再说说参数层面的现实问题。

GET 的参数挂载在URL上，存在天然的长度限制。复杂查询条件一多，URL会变得又长又杂乱。

POST 请求体就没有这个限制，再多参数都可以封装进去，JSON 的数据结构也更加清晰。

安全性上也更占优势。

GET 的参数会留在浏览器地址栏、访问历史、服务器日志、Referer 请求头。一旦不慎混入敏感数据，泄露途径非常多。

POST 的请求体虽然抓包依旧可以读取，但不会被各类组件无意识留存，减少了意外泄露的风险。

缓存也更好把控。GET 请求会被浏览器、CDN 默认缓存，经常出现数据已经更新，用户刷新页面依旧读到旧数据，排查半天根源是缓存问题。

POST 默认不会触发缓存，需要缓存就手动配置，不需要就不会被中间件偷偷篡改返回结果。

当然全用 POST 也存在代价，不能一味只讲好处：

1. 语义丢失：只看HTTP方法，无法分辨接口是查询还是变更操作。不过这个问题可以靠命名弥补，例如  /user/query 、 /user/delete ，通过接口路径直观表达意图。

2. 无法复用HTTP原生缓存。纯查询接口使用 GET，可以借助浏览器、CDN 实现免费缓存；全部使用 POST，缓存逻辑就要自己在业务层实现。

3. 面试容易被追问。如果面试直接说项目全部用POST，大概率会被提问为什么不使用 RESTful，需要自己梳理清楚背后取舍，不然容易显得技术认知浅薄。

那什么场景适合老老实实遵循 RESTful？

对外开放接口。

接口面向外部第三方调用，使用者技术栈五花八门，大家会默认期待接口遵循行业通用标准。像 GitHub API、各类开放平台接口，基本都是 RESTful 风格。

但如果是内部系统、前后端交互的业务接口，统一 POST 体验确实很香。

这里补充一个来自评论区很真实的点：政府、国企类项目，很多时候不得不用POST。

这类项目上线要过等保安全测评。安全检测一旦识别接口使用 PUT、DELETE，就会直接标记风险：接口暴露操作语义，提升被攻击风险，要求整改。

道理听起来有点牵强：即便删掉 PUT、DELETE，POST 照样可以完成删除、修改逻辑，仅仅更换请求方法并不会本质提升安全。

但甲方的安全报告摆在那里，不修改就无法通过验收。因此大量 ToG、ToB 项目，从开发之初就全部采用 POST，避免后期返工整改。

而且这种做法并不是小公司专属，不少大厂内部系统也是这么实践的。

部分内部系统甚至更进一步，所有请求复用同一个URL，依靠请求体内的 action 字段区分业务，偏向 RPC 的思路。

内部系统优先追求开发效率与规范落地，而不是追求技术范式上的漂亮。

RESTful 在简单CRUD场景表现很好，可一旦业务复杂度上来，强行套用反而会变成负担。

说到底，全部接口使用 POST 并不是野路子，而是无数团队踩坑之后做出的务实取舍。

GET、PUT、DELETE 理论很完美，但落地业务处处掣肘。

对于内部业务系统，统一 POST+JSON，开发效率高、规范容易落地，安全也更容易管控。

当然，如果你们团队已经落地一套执行到位的 RESTful 规范，那自然没有问题。

但也不要把全 POST 等同于技术水平低，这是权衡利弊后的选择，不是技术倒退。

很多吐槽“全POST不规范”的人，大概率没有维护过十几人协作、上百个接口的业务项目。等亲身经历一遍，可能也会真香。