首先看一下菜鸟教程中对于 GET
和POST
申请的比拟
对于 HTTP
- 最后是浏览器与服务器之间的通信协定,GET 用于读取资源,POST 用于提交表单
- 起初被裁减到接口格局的定义,
GET
和POST
作为接口的申请形式, 格局如下
{method:{GET/POST}
url:""
header:{}
body:{}}
协定外围包含 method
,url
,header
,body
组成。其中 method
就是形容具体的申请形式,能够是 GET
或POST
或者其余,协定自身并没有要求 GET
申请的参数肯定要放 query
,POST
申请的参数肯定要放 body
,也就是说,从接口定义的角度去看,纯正只是一个申请形式的差别,协定自身并没有对两者做过多的限度,齐全能够把该申请的参数放到body
或把 POST
申请的参数放到 query
,当然过分的放开会减少我的项目开发的沟通老本,升高开发效率。对于下面的问题工程师提出了一系列的解决方案,其中RESULTFUL
接口标准应用面最为宽泛。
GET
申请有下限,POST
传输无下限?
这种说法是比拟全面的,GET
申请参数个别约定俗称的放在 URL
的query
中,而又因为 URL
的长度有下限,因而得出这个论断,而对于 URL
的长度,HTTP 协定自身也没有对 GET
或者 POST
做过多的限度,只是浏览器和服务端别离做了不必水平的限度而已,浏览器 IE 限度在 2048 个字符,Chrome 限度在 2M…
GET 申请:
http://xxx/xx?a=1&b=2
POST 申请:
http://xxx/xx
body:{
"a": 1,
"b": 2
}
为何要这个限度呢?
服务端解析一个字符串时,须要分配内存,而 URL 必须作为一个整体去对待,没有方法分块解决,所以必须调配一块足够大的内存空间来存储 URL。
如果 URL 过长或者并发量过高,就很容易挤爆服务器的内存。
为了解决这个性能问题,所以各端对 URL 长度做了不同水平的限度,这个此案时 GET 申请数据有下限的起因。
POST
比 GET
更平安?
网上常常能够看到 POST
比GET
申请更为平安, 其实是谬误的,正如后面所说,在 HTTP 协定上,GET
和 POST
实质上只是申请形式的不同,协定并没有做过多的限度,只是从标准上,约定俗成的更偏向于把 GET
申请的参数放到 query
中,把 POST
申请的参数放到 body
上,这样相当于 GET
申请的参数间接放到了 URL
上,如果两头带有明码信息,直观上显得并不那么平安,但从网络安全而言,query
和 body
上的参数都是明文的,HTTP 自身就是不平安的协定,申请在任何一个网络节点被劫持,内容都是通明的,况且 GET
和POST
只是申请形式的不同,自身并不对平安起到任何作用,真正要做到平安须要双端加密,如 HTTPS 双端加密后,即便在任何网络节点截取到了包,也截取不到内容,这样才是实质上的平安。