公司规定所有接口都用post请求,这是为什么?
公司规定所有接口都用post请求,这是为什么?
-----
网友解答:
-----
如果请求类型是text,GET和POST完全相同,不同点是在HTTP包的位置上,GET位于HTTP HEADER中,POST在BODY中。
因为GET是在header中,传送数据的长度有限制,而BODY是可以分片的,传送的数据长度就没有限制了。
如果是作为普通的接口协议,用GET更方便。
有人认为POST比GET安全性好,不存在的,两者都是明文传送,如果数据本身不加密,抓个包就看出来了。提高安全性的手段有两个:1、传输协议用https。2、对数据加校验和鉴权防止伪造。
-----
网友解答:
-----
公司的规定不一定就是对的。
GET和POST的最大区别有两个:1、GET是幂等的;2、GET在规范上是不带BODY的,而URL querystring是有长度限制的。根据不同的特性,应用场景不同。
根据我的理解,一般限制调用都是POST,是API服务端开发者为了统一参数解析的方便。
如果遵守RESTful的好处是,很多网络和软硬件基础设施会根据不同类型请求作出相应的优化。比较常见的是,幂等请求会做缓存优化。
技术规范总是标准化和实用性的权衡,没有绝对的对错。
延伸开去,所谓的世俗道德标准,佛教的条条框框也都是如此。因为绝大部分人并不能深刻理解所有东西,这时候就需要一些指导实践的规矩规范。
一边理解一边遵守是对待规范的应有的态度。
-----
网友解答:
-----
我从爬虫的角度来补充下。
如果用get方式,普通小白用chrome的开发工具,查看网络请求,不用任何其他工具,在浏览器地址栏变换参数就可以实现不同的请求。
如果是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把,目的是希望各层都能缓存,加快资源加载速度。
-----
网友解答:
-----
简单说,就是怕你和你的同事蠢,怕你们在get和post上弄出bug还特么找不到出错原因。
-----
网友解答:
-----
1、统一规则,开发人员压根不用去纠结,到底是get还是put还是delete。
2、安全性,post相对还是安全一点的,非要较真的话,带了ssl证书的https请求也可以抓包。至少post请求难度更麻烦一定点。路由器、站点gateway、nginx等等记录日志时,默认都不会记录body中数据。日志泄露也是有风险的
post能做的get其实也能做,只是没几个人这么做。
-----
网友解答:
-----
我司的API框架就是所有接口都是POST提交的。这样做理由有以下几点:
1. 接口调用参数统一,便于开发SDK。
2. 便于传输数组和字典类型参数
3. 便于巡检机器巡检API服务器是否正常
4. 传输参数长度可以足够长
5. 有利于统一H5、后台、App、小程序接口,且SDK一致
-----
网友解答:
-----
post相比get来说,post接口更安全,也更稳定,更规范
get能干的post也能干,get干不了的post还能干
一般post接口也有很多监控工具,比如轻量实用的
wgcloud
wgcloud可以监测接口是否健康,若出现错误还可以告警,功能非常强大,部署使用也简单
-----
网友解答:
-----
简单,就是生产力
加上标点符号,共8各字,这就是为什么公司规定所有接口只用POST请求的
精髓
首先讨论之前,看看规定本身是否存在技术问题,POST是GET能力的超集,GET能做的POST都能做,公司规定不存在技术问题
下面我们一起探讨公司为什么这么做
1,避免犯错,不给你犯错的机会
GET带来的问题
a,GET需要担心URL地址超长导致的问题
b,GET请求浏览器可能会缓存,再请求时,浏览器不发送请求
c,上传文件时,选择GET请求上传不上去
d,多个客户围着公司产品,一个人管理员登陆系统,GET请求时,其他人可以知道他的密码
e,TMD,为什么搜索引擎搜索我的页面后,所有记录都没了,我们系统受到黑客攻击了,后来,一个大牛一看,删除按钮怎么用GET请求做的,程序员说,我有alert呀,大牛酱爆了,\"C,搜索引擎会执行你的javascript吗?\"
如果不允许用GET,这些问题都不用担心
2,减少沟通和学习成本
GET是一个HTTP的知识点,如果用于生产中,我们必须要掌握它的概念,使用场景,和具体如何使用。每次程序员同学犯错后,他本人要学习GET知识,团队要总结教训,制定GET使用规范,公司层面要组织代码检查工具的开发,将GET规范做成自动检查程序,有了规范检查程序后,要制定软件开发IDE的规范,不允许用XXX,只允许用ABC,否则检查不了。对于软件工程中的测试环节,需要把GET犯错的场景做相应的覆盖测试,如果没有对应测试工具,就需要投入资源开发测试工具。系统上线后,运维在反向代理配置的时候,要注意GET和POST不同,文件服务器的代理不能用GET
如上你笑了吗?实际上没有夸张,这就是一个技术细节产生的蝴蝶效应。
人的精力是有限的,如果有更多精力研究POST仅一种技术,那他会把POST掌握的更好
3,降低技术要求,降低工资成本
会POST请求的开发8w,会GET请求开发8w,同时会POST和GET的开发12w
公司A不需要GET技术,只需要花8w招聘一个开发即可
4,提高工作效率,提高市场竞争力
公司所有人员整齐划一,只关心POST,不用开发GET处理逻辑,节省工作量,提前交付,占得市场先机
-----
网友解答:
-----
每种请求方式都有它存在的理由!只用post不过是那家公司的人为了省事罢了。
评论里很多人说我这跟rest风格不符,其实我不过是只借用了其部分规则而已,这里我再补充两张基于About vNext开发的完全遵循rest风格的api图(后两图)供大家参考
-----
网友解答:
-----
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提交大量数据。
欢迎点赞及加关注,谢谢!
------------------
推荐阅读:
上一篇:你们喜欢徐璐吗?
下一篇: 金陵十二钗正册都有谁?