公司规定所有接口都用 post 请求，这是为什么？
只有一个原因，就是为了迁就低水平不思进取的架构师和前后端程序员们。 这问题底下好多津津乐道“这是多年一线开发经验总结出的最佳实践”的人恰好印证了这一点。  看了一下其他答案，全POST的理由大致分两类： 一是反RESTful，用POST替代PUT、DELETE、PATCH等； 姑且还有点道理，REST用Method表达语义其实是很清晰的，但它和传统RPC的思维方式并不直接兼容。而且两者也不是技术上的高低关系，无非是两种接口定义而已。 最怕的就是学个半吊子还简单粗暴硬要上REST，最后弄出个四不像，谁都理解不了。 但有人硬说PUT /api/object看不懂，只能看懂POST /api/updateObject，那只能说你确实该用一个POST包打天下。 如果一个团队有三成的人理解不了REST怎么写login，那还是放弃它吧，免得挖大坑。GET/POST也是很清晰的语法体系啊。  另一种是反GET，理由无外乎url长度和缓存，这就更让人迷惑了。 url长度问题基本都出现在多参数检索中。但是，哪怕用REST语义来分析，复杂检索也本来就该用POST。因为“检索条件-结果”是资源本身而不是一个资源列表，你创建了检索id后可以缓存结果并再次用GET获取。这种原本解决方案十分清晰的问题居然被解释为“GET放不下，我们用POST代替吧”，哭笑不得。 缓存才是不可思议的：无论移动端还是web端都有起码五六种方法来阻止缓存，你可以添加Header，可以在url加时间戳或随机数，可以用Etag，再不济可以手工清除。居然能被这个问题困住而不得不改用POST，莫非只会用浏览器调试API？  全接口POST化绝大部分时候就是为了迁就低水平技术人员。但这种说法有点伤自尊，所以往往会拿“公司统一规定”搪塞。表面显得又标准又规范，实际内里什么样很多人都清楚。 “标准太麻烦，所以堂而皇之地扔掉标准另起炉灶还以此为傲”，这种草台班子心态对一个技术人员的成长是十分有害的。  说到这儿我忽然想起某个强制规定前端一律用div的团队。h1h2h3是div，p是div，label是div，button是div，span是inline的div。语义化是什么？不懂，没用。冠冕堂皇的理由自然是所谓的标准统一好管理不出错。然而为了防止样式混乱，文档里又详细规定了一堆title1、title2、label、btn的class……