认知误区:HTTP Get 、Post的真正区别

经常有技术人员会问你GET\POST有什么区别，通常你会不加思索的回答几个选项。通常大概是：

1. POST比GET安全，因为数据在地址栏上不可见；
2. GET的URL会有长度上的限制，则POST的数据则可以非常大；
3. GET使用URL或Cookie传参。而POST将数据放在Request BODY中；
4. GET请求只能进行url编码，而POST支持多种编码方式;
5. GET回退时是无害的，而POST会再次提交请求;
6. GET请求会被浏览器主动cache,而POST不会除非手动设置;
   ……

其实，以上回答并未完全的有问题。只是，这样只是看到了表象而已。那么本质区别是什么样的呢？
　
HTTP协议是基于TCP/IP协议的，GET/POST也同样应用于TCP/IP,那么GET/POST应该是可以互相使用的(就像在Java中使用service方法处理请求一样)。

那应该如何解释“只看到表象”?

GET和POST与数据如何传递没有关系?

GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪个Method与应用层的数据如何传输是没有相互关系的。

HTTP没有要求，如果Method是POST数据就要放在BODY中。也没有要求，如果Method是GET，数据（参数）就一定要放在URL中而不能放在BODY中。

. HTTP协议对GET和POST都没有对长度的限制

HTTP协议明确地指出了，HTTP头和Body都没有长度的要求。而对于URL长度上的限制，有两方面的原因造成：

浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。
服务器。URL长了，对服务器处理也是一种负担。原本一个会话就没有多少数据，现在如果有人恶意地构造几个几M大小的URL，并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器Content-Length是一个很大的数，然后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此，多数服务器出于安全啦、稳定啦方面的考虑，会给URL长度加限制。但是这个限制是针对所有HTTP请求的，与GET、POST没有关系。

安全不安全和GET、POST没有关系

既然GET也可以设置request body，当然也是可以“安全的”。