Http请求的get 和 post的请求的区别

从表面的意思看get和 post的区别get就是获取数据，post就是发送数据。这个是误区。其实两者都可以的，在IOS向服务器发送请

 

求里面可以带参数。

 

 

那么这些误区是怎么出现的呢？

 

先看看一下对http的解释。一般在浏览器中输入网址访问资源都是通过GET方式；在FORM提交中，可以通过Method指定提交方式为

 

GET或者POST，默认为GET提交。

 

 

Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。 

 

 

URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就

 

对应着对这个资源的查，改，增，删 4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取、查询资源信息，而

 

POST一般用于更新资源信息(个人认为这是GET和POST的本质区别，也是协议设计者的本意，其它区别都是具体表现形式的差异)。

 

 

再进一步了解下他们两个的区别：

 

1. GET使用URL或Cookie传参。而POST将数据放在BODY中。

 

2. GET的URL会有长度上的限制，则POST的数据则可以非常大。

 

3. POST比GET安全，因为数据在地址栏上不可见。

 

 

这些也是有点误区的，就像同步请求一定的慢吗？

 

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

 

GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪

 

Method与应用层的数据如何传输是没有相互关系的。

 

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

 

放在BODY中。

 

那么，网上流传甚广的这个说法是从何而来的呢？我在HTML标准中，找到了相似的描述。这和网上流传的说法一致。但是这只

 

HTML标准对HTTP协议的用法的约定。怎么能当成GET和POST的区别呢？

 

而且，现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出，但是现在的Web Server又不是

 

给浏览器用，已经完全地超出了HTML服务器的范畴了。

 

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

 

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

 

1.浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示

 

同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。

 

2.服务器。URL长了，对服务器处理也是一种负担。原本一个会话就没有多少数据，现在如果有人恶意地构造几个几M大小的URL

 

并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器Content-Length是一个很大的数

 

然后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种故意的次次访问超时也能让服务器吃不

 

兜着走。有鉴于此，多数服务器出于安全啦、稳定啦方面的考虑，会给URL长度加限制。但是这个限制是针对所有HTTP请求的，

 

GET、POST没有关系。

 

3.对于安全不安全讲。

 

get:所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET请求一般不应产生副作用。就是说，它仅仅是获取资源

 

息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。 

 

*注意：这里安全的含义仅仅是指是非修改信息。

 

POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅

 

不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1

 

登录页面有可能被浏览器缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET

 

交数据还可能会造成Cross-site request forgery攻击。