当前位置：首页> 公司规定所有接口都用post请求，这是为什么？> 正文

公司规定所有接口都用post请求，这是为什么？

用户2527463001
2023-05-25
60
共10人回复

「光明右使8787 」发表看法

2023-05-31

如果请求类型是text，GET和POST完全相同，不同点是在HTTP包的位置上，GET位于HTTP HEADER中，POST在BODY中。

因为GET是在header中，传送数据的长度有限制，而BODY是可以分片的，传送的数据长度就没有限制了。

如果是作为普通的接口协议，用GET更方便。

有人认为POST比GET安全性好，不存在的，两者都是明文传送，如果数据本身不加密，抓个包就看出来了。提高安全性的手段有两个：1、传输协议用https。2、对数据加校验和鉴权防止伪造。

「正宗乌龟鱼」发表看法

2023-06-01

公司的规定不一定就是对的。

GET和POST的最大区别有两个：1、GET是幂等的；2、GET在规范上是不带BODY的，而URL querystring是有长度限制的。根据不同的特性，应用场景不同。

根据我的理解，一般限制调用都是POST，是API服务端开发者为了统一参数解析的方便。

如果遵守RESTful的好处是，很多网络和软硬件基础设施会根据不同类型请求作出相应的优化。比较常见的是，幂等请求会做缓存优化。

技术规范总是标准化和实用性的权衡，没有绝对的对错。

延伸开去，所谓的世俗道德标准，佛教的条条框框也都是如此。因为绝大部分人并不能深刻理解所有东西，这时候就需要一些指导实践的规矩规范。

一边理解一边遵守是对待规范的应有的态度。

「自由践行」发表看法

2023-05-29

我从爬虫的角度来补充下。

如果用get方式，普通小白用chrome的开发工具，查看网络请求，不用任何其他工具，在浏览器地址栏变换参数就可以实现不同的请求。

如果是post方式，浏览器输入参数就不管用了，必须要借助工具才行。

当然对可以有编程能力的还是防不住，不过可以阻挡大部分小白的探索了。

「紫夜追风者」发表看法

2023-05-30

前面很多观点，基本上正确，我补充几个如果在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把，目的是希望各层都能缓存，加快资源加载速度。

「李小啵啵」发表看法

2023-05-31

1、统一规则，开发人员压根不用去纠结，到底是get还是put还是delete。

2、安全性，post相对还是安全一点的，非要较真的话，带了ssl证书的https请求也可以抓包。至少post请求难度更麻烦一定点。路由器、站点gateway、nginx等等记录日志时，默认都不会记录body中数据。日志泄露也是有风险的

post能做的get其实也能做，只是没几个人这么做。

「老汉篮球」发表看法

2023-06-02

API接口使用POST主要是基于安全、用户体验、标准化等方面考虑吧。

都把公司逼到出这种规定了，可见你们公司那些程序员多懒散，呵呵。我觉得能不用GET就尽量不用，理由如下：

提交少量数据可使用GET

GET一般只用来提交数据量比较小的参数，如ID、查询关键字等。而上传文件等数据量大的操作则使用POST。

后台提交格式化数据应用POST

提交XML、JSON等格式化数据要使用POST，这点有点经验的人应该能明白，谁见过有用GET提交XML的？

前台使用GET可提升用户体验

使用GET方式方便在链接中传参数，用户复制粘贴，转发、收藏及修改都比较方便，否则难道要用户自己修改HTML表单参数吗？当然，API是不用考虑用户体验的，所以使用POST完全没问题。

安全也是重要的因素

使用GET提交的数据会保存在浏览器历史记录及服务器访问日志中，除了网站服务器，代理服务器、反向代理服务器及网络安全设备等也可能会保存，如果URL中能看到用户密码，那还有什么安全性可言？所以密码等敏感数据，一定要使用POST方式提交。

另外，我们知道访问日志一般不保存POST数据，最主要原因是POST提交的数据有可能很大，很轻易就会把日志的存储空间占满，从而导致DOS漏洞。所以，要避免使用GET提交大量数据。

欢迎点赞及加关注，谢谢！

「科技素人特工」发表看法

2023-06-03

GET带来的问题

1、GET请求URL地址超长导致的问题

2、GET请求浏览器可能会缓存

3、如果用GET请求去实现写操作，搜索引擎如果抓到了这个链接。。。

POST请求是GET的超集，GET能做的事情POST都能做，所以一些公司为了避免上述问题偷懒直接规定不能用GET。但是这不是最优做法，也是不规范的做法。

「青涩清风3h 」发表看法

2023-06-01

统一，灵活，易维护。

只用POST也可以设计RESTFUL风格的API.

POST请求和回应可以承载不同的PAYLOAD.可以是json.可以是protocolbuf，可以xml，可以SOAP.可以是二进制。还可以利用http 1.1 chunked transfer传输文件流。开始利用易读易维护的json格式，后期将有序列化性能要求的重构到protocolbuf依靠框架能力也是非常平滑，不必纠结早期的过度优化。将以POST方式传输请求和回应的json理解成消息机制，迁移到MQ也是小菜一碟。轻装上阵，又留有余地。

POST没有GET请求可能遇到的中间http缓存问题。

总之，全用POST请求并不少见。

「七山老友」发表看法

2023-06-03

作为一名安全工程师，有必要解释一下。

get传输账号密码，中间通过运营商的nginx或者类似7层代理，直接日志中就可以看到

post传输账号密码，你的通过抓包分析才能看到账号密码。

所以对比post比get更加安全，看楼上的同学不认同post比get更安全，认为都可以通过办法破解，这是对安全理解不一样。其实按您说的https也能被破解的，安全不是你做了啥就一定安全，而是你做了啥提高了安全性，明显一个通过看日志就能获得账号密码，一个需要抓包分析，那个难度大一点？

「风趣运维工程狮」发表看法

2023-05-30

公司规定所有接口都用POST请求的原因可能有多种，下面我将从安全性、性能、可读性和适用性四个方面进行分析。

第一，安全性。在互联网应用程序中，安全性一直是最受关注的问题之一。使用POST请求可以更好地保护敏感信息，因为使用POST请求时，参数会放在请求体中，而不是像GET请求一样暴露在URL中，这可以有效防止URL被篡改或泄漏敏感信息。

第二，性能。POST请求通常比GET请求慢，因为POST请求需要发送更多的数据，并且需要在服务器上处理更多的数据。但是，对于大多数应用程序来说，这种差异很小，并不会对性能造成重大影响。并且，在处理非常大的请求和响应时，POST请求可能会更快，因为浏览器可以使用分块传输编码（chunked transfer encoding）来在请求和响应中传输大量数据，它可以将请求或响应分解成多个部分并分别发送。

第三，可读性。相对于GET请求，POST请求可以更好地组织和管理请求参数。使用POST请求时，参数通常存储在请求体中，这使得参数可以更好地组织和管理，并且可以使用JSON等格式来更清晰地表示参数。

第四，适用性。POST请求可以发送任何类型的数据，而GET请求只能发送ASCII字符。因此，在处理文件上传、复杂查询等场景时，POST请求比GET请求更适用。

总之，公司规定所有接口都用POST请求可能是为了提高应用程序的安全性、可读性和适用性。虽然POST请求通常比GET请求更慢，但在大多数情况下，这种差异很小。当然，在某些特定场景下，GET请求可能会更适用，例如缓存静态资源等。因此，选择GET或POST请求，需要根据具体情况来进行选择。