段勇宾
公司的规定不一定就是对的。
GET和POST的最大区别有两个：1、GET是幂等的；2、GET在规范上是不带BODY的，而URL querystring是有长度限制的。根据不同的特性，应用场景不同。
根据我的理解，一般限制调用都是POST，是API服务端开发者为了统一参数解析的方便。
如果遵守RESTful的好处是，很多网络和软硬件基础设施会根据不同类型请求作出相应的优化。比较常见的是，幂等请求会做缓存优化。
技术规范总是标准化和实用性的权衡，没有绝对的对错。
延伸开去，所谓的世俗道德标准，佛教的条条框框也都是如此。因为绝大部分人并不能深刻理解所有东西，这时候就需要一些指导实践的规矩规范。
一边理解一边遵守是对待规范的应有的态度。
正宗乌龟鱼
每种请求方式都有它存在的理由！只用post不过是那家公司的人为了省事罢了
笨瓜1号
如果请求类型是text，GET和POST完全相同，不同点是在HTTP包的位置上，GET位于HTTP HEADER中，POST在BODY中。
因为GET是在header中，传送数据的长度有限制，而BODY是可以分片的，传送的数据长度就没有限制了。
如果是作为普通的接口协议，用GET更方便。
有人认为POST比GET安全性好，不存在的，两者都是明文传送，如果数据本身不加密，抓个包就看出来了。提高安全性的手段有两个：1、传输协议用https。2、对数据加校验和鉴权防止伪造。
光明右使8787
前面很多观点，基本上正确，我补充几个如果在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把，目的是希望各层都能缓存，加快资源加载速度。
紫夜追风者
我司的API框架就是所有接口都是POST提交的。这样做理由有以下几点：
1. 接口调用参数统一，便于开发SDK。
2. 便于传输数组和字典类型参数
3. 便于巡检机器巡检API服务器是否正常
4. 传输参数长度可以足够长
5. 有利于统一H5、后台、App、小程序接口，且SDK一致
web架构师自我修炼
[哈欠]个人感觉不是很好！post倒是可以避免get的参数过程，参数暴露等缺陷，但出现就有其出现的道理，restful风格一直是我追随的！不过主要看公司使用场景！
华夏紫穹
\n
{!-- PGC_VIDEO:{"thumb_height": 360, "thumb_url": "2beed00073a222a64bcac\
倩倩的成长日记vlog
统一后减少出错概率；避免结果被缓存问题；避免url接口长度限制；调试更方便跟踪数据，不存在url转义的问题
瓶子的光芒
因为你们公司水平有问题 post携带内容多 get速度快压力小 post用来提交表单什么的 get用来做简单参数请求什么的 其他其实没啥区别
星空倒影988
Post和get区别不大 第一点区别服务器缓存 第二点冪等性 第三点也是最大的区别 设计目的不同
