共计 1155 个字符，预计需要花费 3 分钟才能阅读完成。
首先看一下菜鸟教程中对于 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 双端加密后，即便在任何网络节点截取到了包，也截取不到内容，这样才是实质上的平安。
