GET和POST两种基本请求方法的区别

GET和POST是HTTP请求的两种基本方法，要说它们的区别，接触过WEB开发的人都能说出一二。

 

最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。

 

你可能自己写过无数个GET和POST请求，或者已经看过很多权威网站总结出的他们的区别，你非常清楚知道什么时候该用什么。

 

当你在面试中被问到这个问题，你的内心充满了自信和喜悦。

你轻轻松松的给出了一个“标准答案”：

• GET在浏览器回退时是无害的，而POST会再次提交请求。

   

• GET产生的URL地址可以被Bookmark，而POST不可以。

   

• GET请求会被浏览器主动cache，而POST不会，除非手动设置。

   

• GET请求只能进行url编码，而POST支持多种编码方式。

   

• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

   

• GET请求在URL中传送的参数是有长度限制的，而POST么有。

   

• 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

   

• GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

   

• GET参数通过URL传递，POST放在Request body中。

（本标准答案参考自w3schools）

 

“很遗憾，这不是我们要的回答！”

请告诉我真相。。。

如果我告诉你GET和POST本质上没有区别你信吗？
让我们扒下GET和POST的外衣，坦诚相见吧！

GET和POST是什么？HTTP协议中的两种发送请求的方法。

 

HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。

 

HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。 

 

那么，“标准答案”里的那些区别是怎么回事？

 

在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。

 

但是，我们只看到HTTP对GET和POST参数的传送渠道（url还是requrest body）提出了要求。“标准答案”里关于参数大小的限制又是从哪来的呢？

 

在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。

 

好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。 

 

你以为本文就这么结束了？

 

我们的大BOSS还等着出场呢。。。

 

这位BOSS有多神秘？当你试图在网上找“GET和POST的区别”的时候，那些你会看到的搜索结果里，从没有提到他。他究竟是什么呢。。。

 

GET和POST还有一个重大区别，简单的说：

GET产生一个TCP数据包；POST产生两个TCP数据包。

 

长的说：

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

 

也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

 

因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？

1. GET与POST都有自己的语义，不能随便混用。

2. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查，改，增，删4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。

1，http中，GET用于信息获取，而且是安全的和幂等的。

(1).所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET 请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。

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

(2).幂等的意味着对同一URL的多个请求应该返回同样的结果。

2，http中，POST是用于修改服务器上的资源的请求。

说完原理性的问题，我们从表面上来看看GET和POST的区别：

1. get是从服务器上获取数据，post是向服务器传送数据。 
get 和 post只是一种传递数据的方式，get也可以把数据传到服务器，他们的本质都是发送请求和接收结果。只是组织格式和数据量上面有差别，http协议里面有介绍
  2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。 
因为get设计成传输小数据，而且最好是不修改服务器的数据，所以浏览器一般都在地址栏里面可以看到，但post一般都用来传递大数据，或比较隐私的数据，所以在地址栏看不到，能不能看到不是协议规定，是浏览器规定的。
3. 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。 怎么获得变量和你的服务器有关，和get或post无关，服务器都对这些请求做了封装。
  4. get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 post基本没有限制，我想大家都上传过文件，都是用post方式的。只不过要修改form里面的那个type参数
  5. get安全性非常低，post安全性较高。 

如果没有加密，他们安全级别都是一样的，随便一个监听器都可以把所有的数据监听到。

6. get把请求的数据放在url上，即HTTP协议头上，其格式为：
以?分割URL和传输数据，参数之间以&相连。
数据如果是英文字母/数字，原样发送，
如果是空格，转换为+，
如果是中文/其他字符，则直接把字符串用BASE64加密，及“%”加上“字符串的16进制ASCII码”。
post把数据放在HTTP的包体内（requrest body）。

7.分析

　　一般在浏览器中输入网址访问资源都是通过GET方式；在FORM提交中，可以通过Method指定提交方式为GET或者POST，默认为GET提交。Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。

　　URL全称是资源描述符，我们可以这样认 为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 、改 、增 、删 4个操作。

　　根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的，可以参见安全的(Safe)和幂等的(Idempotent)。

1. 安全的是指没有明显的对用户有影响的副作用(包括修改该资源的状态)。HTTP方法里的GET和HEAD都是安全的。
2. 幂等的是指一个方法不论多少次操作，结果都是一样。PUT(把内容放到指定URL)，DELETE(删除某个URL代表的资源)，虽然都修改了资源内容，但多次操作，结果是相同的，因此和HEAD，GET一样都是幂等的。

　　所以根据HTTP协议，GET是安全的，也是幂等的，而POST既不是安全的，也不是幂等的。但在实际应用中，以上2条规定并没有这么严格。比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的。因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看没有改变资源即可。

通常情况下我们都说POST的安全性要比GET的安全性高(注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义)，比如：通过GET提交数据，用户名和密码将明文出现在URL上，比如有一个常见的url：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD，通过这个url我们就知道该用户的用户名是：hyddd，密码是idontknow。但是就因为这个原因说 POST 比 GET 安全是错的，因为POST和GET都是明文传输，用httpfox等插件，或者像WireShark 等类似工具就能观察到。

　　POST和GET的差别其实是很大的。语义上，GET是获取指定URL上的资源，是读操作，重要的一点是不论对某个资源GET多少次，它的状态是不会改变的，在这个意义上，我们说GET是安全的（不是被密码学或者数据保护意义上的安全）。因为GET是安全的，所以GET返回的内容可以被浏览器，Cache服务器缓存起来（其中还有很多细节，但不影响这里的讨论）。

　　而POST的语意是对指定资源“追加/添加”数据，所以是不安全的，每次提交的POST，参与的代码都会认为这个操作会修改操作对象资源的状态，于是，浏览器在你按下F5的时候会跳出确认框，缓存服务器不会缓存POST请求返回内容。而POST的语意是对指定资源“追加/添加”数据，所以是不安全的，每次提交的POST，参与的代码都会认为这个操作会修改操作对象资源的状态，于是，浏览器在你按下F5的时候会跳出确认框，缓存服务器不会缓存POST请求返回内容。

很遗憾到目前为止没有应聘者能够提到这一点。我猜测这背后的原因大概有两个，一是也许大多数人往往（我也一样）满足于只要完成任务就好，不管用哪个，表单提交了，数据处理了，内容显示或者重新定向到另外一个页面，就算完成了一个任务，从任务表里划掉，结束。而且对大部分项目(OA, CRM, MIS)的大部分情况下，用哪个似乎都可以。

同时，在被商业机构在媒体和书籍上宣传兜售的WS-*概念和使用集成开发环境提供的“方便”的代码生成工具后，“了解”到所有Web服务调用都是通过POST，更潜意识里确定了POST和GET是一样的，而且GET能做的，POST都能做，POST简直就是GET++嘛。自然，能用POST就用POST，不必在乎两者的差别了。

这又让我想起最近学到的一个概念: Radius Of Comprehension，理解的半径:

当学习概念A的时候，需要先了解概念B，而概念C又是理解B的前提。当B和C都是新的需要学习的概念时，可以说A的理解半径是2，如图:

A --> B --> C
|--1--|--2--|

在学习Web开发时，接触到GET和POST时，“理解的半径”可能包涵:

POST vs. GET
     |---> Conditional GET -> ETag -> Cache
     |         `--> Status Code
     `---> HTTP的方法 --> URL

往往因为仅仅满足于完成手上被要求的任务，或者懒于问一个为什么，我们就把自己的理解半径设置成零，那么就学不到更深入的东西，也因此仅仅知道POST和GET不同，而不再会了解不同在哪里，什么是Conditional GET和缓存header等概念。

安全的是指没有明显的对用户有影响的副作用(包括修改该资源的状态)。HTTP方法里的GET和HEAD都是安全的。

幂等的是指一个方法不论多少次操作，结果都是一样。PUT(把内容放到指定URL)，DELETE(删除某个URL代表的资源)，虽然都修改了资源内容，但多次操作，结果是相同的，因此和HEAD，GET一样都是幂等的。

所以根据HTTP协议，GET是安全的，也是幂等的，而POST既不是安全的，也不是幂等的。