公司规定所有接口都用post请求，这是为什么？
⇆a公司规定所有接口都用post请求，这是为什么？
如果请求类型是text，GET和POST完全相同，不同点是在HTTP包的位置上，GET位于HTTP HEADER中，POST在BODY中。
因为GET是在header中，传送数据的长度有限制，而BODY是可以分片的，传送的数据长度就没有限制了。
如果是作为普通的接口协议，用GET更方便。
有人认为POST比GET安全性好，不存在的，两者都是明文传送，如果数据本身不加密，抓个包就看出来了。提高安全性的手段有两个：1、传输协议用https。2、对数据加校验和鉴权防止伪造。
▅▴公司规定所有接口都用post请求，这是为什么？
公司的规定不一定就是对的。
GET和POST的最大区别有两个：1、GET是幂等的；2、GET在规范上是不带BODY的，而URL querystring是有长度限制的。根据不同的特性，应用场景不同。
根据我的理解，一般限制调用都是POST，是API服务端开发者为了统一参数解析的方便。
如果遵守RESTful的好处是，很多网络和软硬件基础设施会根据不同类型请求作出相应的优化。比较常见的是，幂等请求会做缓存优化。
技术规范总是标准化和实用性的权衡，没有绝对的对错。
延伸开去，所谓的世俗道德标准，佛教的条条框框也都是如此。因为绝大部分人并不能深刻理解所有东西，这时候就需要一些指导实践的规矩规范。
一边理解一边遵守是对待规范的应有的态度。
⇩☩公司规定所有接口都用post请求，这是为什么？
我从爬虫的角度来补充下。
如果用get方式，普通小白用chrome的开发工具，查看网络请求，不用任何其他工具，在浏览器地址栏变换参数就可以实现不同的请求。
如果是post方式，浏览器输入参数就不管用了，必须要借助工具才行。
当然对可以有编程能力的还是防不住，不过可以阻挡大部分小白的探索了。
⇟ℕ公司规定所有接口都用post请求，这是为什么？
前面很多观点，基本上正确，我补充几个如果在get上带参数遇到过的问题，大家可以作为参考，以下观点不考虑在https已经加密的情况下讨论。
无论get或者是body，都是明文传输，有人提到protobuf，自定义字节流协议等，这种是属于传输的协议，明文的意思是可以捉取到你传输的内容。这种属于数据传输中包体的协议部分，参考Content-Type说明。
1. 如果参数全在url上，很容易被中间的路由所记录，比如你正在登录，但帐号以及密码就放在url里，哪天中间路由的日志被爬走了，你的登录信息就泄露了。
但body就不会被记录，并不是不能被记录，但body一般大很多，而且还有图片文件等字节流，一般是不会被记录下来的。
参考：tomcat的access日志，nginx的access日志，路由日志等
2. 每个浏览器限制的url长度并不是固定的，当超过一定长度时，每个用户得到的结果就有可能不一致。例如：有可能chrome没问题，ie或firefox就报错，作为后台是不愿意看到这种情况的，使用Post就可以很好的避免
3. 每个中间转发层header的大小也是不一定的，比如nginx有个参数large_client_header_buffers，如果超过了，就会得到一个错误：error code 414: uri too large。而且中间转发层可能不止一个，没必要踩这种坑对吧。
4. get请求很容易被浏览器进行缓存，导致你需要增加一个随机参数避免缓存命中。
5. 某些网关还会缓存get请求，目的是减少网关交叉访问时的费用，这种情况更不好控制。
所以规定只能POST可以很大程度规避一些坑，每次把<为什么>给每个人说清楚还是比较困难的，但做成规定，可以很大程度上避免重复遇到问题。
而当你真的需要用上缓存时，例如前端资源js、css、页面加载等，就用get把，目的是希望各层都能缓存，加快资源加载速度。
Ⓤ➡公司规定所有接口都用post请求，这是为什么？
简单说，就是怕你和你的同事蠢，怕你们在get和post上弄出bug还特么找不到出错原因。
------------------
推荐阅读：
宝宝晚上睡觉特别爱闹腾，易醒爱哼唧，喂了葡萄糖酸锌钙也没用，怎么办？
上一篇：为什么现在的人都向体制看齐？
下一篇： 经常眼睛干涩怎么办？
