首先看一下菜鸟教程中对于GET和POST申请的比拟

对于HTTP

  1. 最后是浏览器与服务器之间的通信协定，GET用于读取资源，POST用于提交表单
  2. 起初被裁减到接口格局的定义，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=2POST申请:http://xxx/xxbody:{  "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双端加密后，即便在任何网络节点截取到了包，也截取不到内容，这样才是实质上的平安。