HTTP 方法：GET 对比 POST

两种最常用的 HTTP 方法是：GET 和 POST。

什么是 HTTP？

超文本传输协议（HTTP）的设计目的是保证客户机与服务器之间的通信。

HTTP 的工作方式是客户机与服务器之间的请求-应答协议。

web 浏览器可能是客户端，而计算机上的网络应用程序也可能作为服务器端。

举例：客户端（浏览器）向服务器提交 HTTP 请求；服务器向客户端返回响应。响应包含关于请求的状态信息以及可能被请求的内容。

两种 HTTP 请求方法：GET 和 POST

在客户机和服务器之间进行请求-响应时，两种最常被用到的方法是：GET 和 POST。

• GET - 从指定的资源请求数据。
• POST - 向指定的资源提交要被处理的数据

GET 方法

请注意，查询字符串（名称/值对）是在 GET 请求的 URL 中发送的：

/test/demo_form.asp?name1=value1&name2=value2

有关 GET 请求的其他一些注释：

• GET 请求可被缓存
• GET 请求保留在浏览器历史记录中
• GET 请求可被收藏为书签
• GET 请求不应在处理敏感数据时使用
• GET 请求有长度限制
• GET 请求只应当用于取回数据

POST 方法

请注意，查询字符串（名称/值对）是在 POST 请求的 HTTP 消息主体中发送的：

POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2

有关 POST 请求的其他一些注释：

• POST 请求不会被缓存
• POST 请求不会保留在浏览器历史记录中
• POST 不能被收藏为书签
• POST 请求对数据长度没有要求

比较 GET 与 POST

下面的表格比较了两种 HTTP 方法：GET 和 POST。

	GET	POST
后退按钮/刷新	无害	数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
书签	可收藏为书签	不可收藏为书签
缓存	能被缓存	不能缓存
编码类型	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史	参数保留在浏览器历史中。	参数不会保存在浏览器历史中。
对数据长度的限制	是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。	无限制。
对数据类型的限制	只允许 ASCII 字符。	没有限制。也允许二进制数据。
安全性	与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。 在发送密码或其他敏感信息时绝不要使用 GET ！	POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性	数据在 URL 中对所有人都是可见的。	数据不会显示在 URL 中。

其他 HTTP 请求方法

下面的表格列出了其他一些 HTTP 请求方法：

方法	描述
HEAD	与 GET 相同，但只返回 HTTP 报头，不返回文档主体。
PUT	上传指定的 URI 表示。
DELETE	删除指定资源。
OPTIONS	返回服务器支持的 HTTP 方法。
CONNECT	把请求连接转换到透明的 TCP/IP 通道。

表单提交中get和post方式的区别 （一）

表单提交中get和post方式的区别有5点 
1.get是从服务器上获取数据，post是向服务器传送数据。 
2.get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTPpost机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。 
3.对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。 
4.get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 
5.get安全性非常低，post安全性较高。

HTTP请求：get与post方法的区别 
HTTP 定义了与服务器交互的不同方法，最基本的方法是 get 和 post。事实上 get 适用于多数请求，而保留 post仅用于更新站点。根据 HTTP 规范，get 用于信息获取，而且应该是安全的和幂等的。所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，get 请求一般不应产生副作用。幂等的意味着对同一 URL的多个请求应该返回同样的结果。完整的定义并不像看起来那样严格。从根本上讲，其目标是当用户打开一个链接时，她可以确信从自身的角度来看没有改变资源。比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。反之亦然。post请求就不那么轻松了。post 表示可能改变服务器上的资源的请求。仍然以新闻站点为例，读者对文章的注解应该通过 post请求实现，因为在注解提交之后站点已经不同了（比方说文章下面出现一条注解）； 
在FORM提交的时候，如果不指定Method，则默认为get请求，Form中提交的数据将会附加在url之后，以?分开与url分开。字母数字字符原样发送，但空格转换为“+“号，其它符号转换为%XX,其中XX为该符号以16进制表示的ASCII（或ISOLatin-1）值。get请求请提交的数据放置在HTTP请求协议头中，而post提交的数据则放在实体数据中； 
get方式提交的数据最多只能有1024字节，而post则没有此限制。 
在表单里使用”post”和”get”有什么区别 
在Form里面，可以使用post也可以使用get。它们都是method的合法取值。但是，post和get方法在使用上至少有两点不同： 
1、get方法通过URL请求来传递用户的输入。post方法通过另外的形式。 
2、get方式的提交你需要用Request.QueryString来取得变量的值，而post方式提交时，你必须通过Request.Form来访问提交的内容。 
仔细研究下面的代码。你可以运行之来感受一下： 
代码 
〈!–两个Form只有Method属性不同–〉 
〈FORM ACTION=“getpost.asp” METHOD=“get”? 
〈INPUT TYPE=“text” NAME=“Text” VALUE=“Hello World”〉〈/INPUT〉 
〈INPUT TYPE=“submit” VALUE=“Method=get”〉〈/INPUT〉 
〈/FORM〉 
〈BR〉 
〈FORM ACTION=“getpost.asp” METHOD=“post”〉 
〈INPUT TYPE=“text” NAME=“Text” VALUE=“Hello World”〉〈/INPUT〉 
〈INPUT TYPE=“submit” VALUE=“Method=post”〉〈/INPUT〉 
〈/FORM〉 
〈BR〉 
〈BR〉 
〈% If Request.QueryString(“Text”) 〈〉 ““ Then %〉 
通过get方法传递来的字符串是： “〈B〉〈%= Request.QueryString(“Text”) %〉〈/B〉“〈BR〉 
〈% End If %〉 
〈% If Request.Form(“Text”) 〈〉 ““ Then %〉 
通过post方法传递来的字符串是： “〈B〉〈%= Request.Form(“Text”) %〉〈/B〉“〈BR〉 
〈% End If %〉 
说明 
把上面的代码保存为getpost.asp，然后运行，首先测试post方法，这时候，浏览器的url并没有什么变化，返回的结果是： 
通过post方法传递来的字符串是： "Hello World" 
然后测试用get方法提交，请注意，浏览器的url变成了： 
http://localhost/general/form/getpost.asp?Text=Hello+World 
而返回的结果是： 
通过get方法传递来的字符串是： "Hello World" 
最后再通过post方法提交，浏览器的url还是： 
http://localhost/general/form/getpost.asp?Text=Hello+World 
而返回的结果变成： 
通过get方法传递来的字符串是： "Hello World" 
通过post方法传递来的字符串是： "Hello World" 
提示 
通过get方法提交数据，可能会带来安全性的问题。比如一个登陆页面。当通过get方法提交数据时，用户名和密码将出现在URL上。如果： 
１、 登陆页面可以被浏览器缓存； 
２、 其他人可以访问客户的这台机器。 
那么，别人即可以从浏览器的历史记录中，读取到此客户的账号和密码。所以，在某些情况下，get方法会带来严重的安全性问题。 
建议 
http://www.devdao.com/
在Form中，建议使用post方法。 
get与post的区别2 
get：是以实体的方式得到由请求URI所指定资源的信息，如果请求URI只是一个数据产生过程，那么最终要在响应实体中返回的是处理过程的结果所指向的资源，而不是处理过程的描述。 
post：用来向目的服务器发出请求，要求它接受被附在请求后的实体，并把它当作请求队列中请求URI所指定资源的附加新子项，post被设计成用统一的方法实现下列功能： 
1：对现有资源的解释 
2：向电子公告栏、新闻组、邮件列表或类似讨论组发信息。 
3：提交数据块 
4：通过附加操作来扩展数据库 
从上面描述可以看出，get是向服务器发索取数据的一种请求；而post是向服务器提交数据的一种请求，要提交的数据位于信息头后面的实体中。 
很理论化，但是很标准，method=“get”并不是从服务器上获取数据，get和post 只是发送机制不同，并不是一个取一个发！ 
get方法会在IE地址栏里显示表示你提交时候所带的值；post方法不会 
1、get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTPpost机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。 
2、对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。两种方式的参数都可以用Request来获得。 
3、get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 
4、get安全性非常低，post安全性较高。 
5、 〈form method="get" action="a.asp?b=b"〉跟〈form method="get"action="a.asp"〉是一样的，也就是说，action页面后边带的参数列表会被忽视；而〈formmethod="post" action="a.asp?b=b"〉跟〈form method="post"action="a.asp"〉是不一样的。 
另外，get请求有如下特性：它会将数据添加到URL中，通过这种方式传递到服务器，通常利用一个问号？代表URL地址的结尾与数据参数的开端，后面的参数每一个数据参数以“名称=值”的形式出现，参数与参数之间利用一个连接符&来区分。 
post请求有如下特性：数据是放在HTTP主体中的，其组织方式不只一种，有&连接方式，也有分割符方式，可隐藏参数，传递大批数据，比较方便。 
post 地址栏不会出现一大串?bjnghfgreygt这样的东西 
如果是get，就会出现了 
1、get 方法通过 URL 请求来传递用户的数据，将表单内各字段名称与其内容，以成对的字符串连接，置于 action 属性所指程序的 url后，如http://www.mdm.com/test.asp?name=asd&passWord=sad，数据都会直接显示在 url 上，就像用户点击一个链接一样；post 方法通过 HTTP post 机制，将表单内各字段名称与其内容放置在 HTML表头(header)内一起传送给服务器端交由 action属性能所指的程序处理，该程序会通过标准输入(stdin)方式，将表单的数据读出并加以处理 
2、 get 方式需要使用 Request.QueryString 来取得变量的值；而 post 方式通过 Request.Form 来访问提交的内容 
3、 get 方式传输的数据量非常小，一般限制在 2 KB 左右，但是执行效率却比 post 方法好；而 post方式传递的数据量相对较大，它是等待服务器来读取数据，不过也有字节限制，这是为了避免对服务器用大量数据进行恶意攻击，根据微软方面的说法，微软对用 Request.Form() 可接收的最大数据有限制，IIS 4 中为 80 KB 字节，IIS 5 中为 100 KB 字节 
建议：除非你肯定你提交的数据可以一次性提交，否则请尽量用 post 方法 
4、 get 方式提交数据，会带来安全问题，比如一个登陆页面，通过 get 方式提交数据时，用户名和密码将出现在 URL上，如果页面可以被缓存或者其他人可以访问客户这台机器，就可以从历史记录获得该用户的帐号和密码，所以表单提交建议使用 post 方法；post方法提交的表单页面常见的问题是，该页面如果刷新的时候，会弹出一个对话框 
1、get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTPpost机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。 
2、 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。两种方式的参数都可以用Request来获得。 
3、get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。 
4、get安全性非常低，post安全性较高。 
5、〈form method="get" action="a.asp?b=b"〉跟〈form method="get"action="a.asp"〉是一样的，也就是说，action页面后边带的参数列表会被忽视；而〈formmethod="post" action="a.asp?b=b"〉跟〈form method="post"action="a.asp"〉是不一样的。

get和post区别（二）

作者：杨光
链接：https://www.zhihu.com/question/28586791/answer/145424285
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
 

HTTP协议中GET和POST方法的区别已经是老生常谈了，也是面试热门问题，我之前对此也只有一个粗浅的印象，这里来认真探讨一下。

通常的理解

w3schools关于这个问题的解答：HTTP 方法：GET 对比 POST 列出了一般的理解，比如：

 

GET后退按钮/刷新无害，POST数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
GET书签可收藏，POST为书签不可收藏。
GET能被缓存，POST不能缓存 。
GET编码类型application/x-www-form-url，POST编码类型encodedapplication/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
GET历史参数保留在浏览器历史中。POST参数不会保存在浏览器历史中。
GET对数据长度有限制，当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。POST无限制。
GET只允许 ASCII 字符。POST没有限制。也允许二进制数据。
与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。在发送密码或其他敏感信息时绝不要使用 GET ！POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
GET的数据在 URL 中对所有人都是可见的。POST的数据不会显示在 URL 中。

 

这个对比整体没什么毛病，但只是给出了一些现象上的区别，但并没有解释为什么，对于这个问题的理解不能就停在这一层。

理解错了？

有一篇文章99%的人理解错 HTTP 中 GET 与 POST 的区别，否定了上述回答：“很遗憾，这不是我们要的回答！”，作者说：

GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。 GET和POST还有一个重大区别，简单的说：GET产生一个TCP数据包；POST产生两个TCP数据包。
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）； 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

都讲到TCP了，感觉很高大上有木有，起码当时看到这篇文章的我是信了的。

反转？？

但是在逛知乎时又看到了这篇文章：听说『99% 的人都理解错了 HTTP 中 GET 与 POST 的区别』？？，指出了前文的两个错误：

100 continue 只有在请求里带了Expect: 100-continueheader 的时候才有意义。
When the request contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in Section 5.1.1. The client ought to continue sending the request and discard the 100 response. If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response.

 

我们通常在讨论 GET vs POST 的时候，实际上讨论的是 specification，而不是 implementation。什么是 specification？说白了就是相关的 RFC。implementation 则是所有实现了 specification 中描述的代码/库/产品，比如 curl，Python 的 requests 库，或者 Chrome。
POST 请求怎么发送，根本就不是这段 RFC 在讨论的事情。RFC 中只说明了 100 continue 和 Expect header 的联系，比如你想在 GET 请求里带 body，一样可以发送 Expect: 100-continue 并等待 100 continue，这是符合标准的。
也就是说，『XHR 发送两个 TCP packets』是关于 implementation 的知识，而不是关于 specification 的知识。你不能说『Chrome 在 AJAX POST 的时候会发两个 TCP packets，GET 只会发一个』是 GET 和 POST 的区别，正如你不能因为北京 PM 2.5 经常爆表就说国家关于工业废气排放的标准有问题。

说得似乎更有道理，而且也搬出了RFC，specification，implementation这些高端词汇，这下子我这个吃瓜群众再也坐不住了，决定亲自去研究一下。

RFC探秘

首先，什么是RFC呢？Wiki上面的定义是：

征求意见稿（英语：Request For Comments，缩写为RFC），是由互联网工程任务组（IETF）发布的一系列备忘录。文件收集了有关互联网相关信息，以及UNIX和互联网社区的软件文件，以编号排定。目前RFC文件是由互联网协会（ISOC）赞助发行。

简单理解RFC就是互联网的规范，我们通常所说的「协议」就是以RFC的形式存在，而现行的HTTP/1.1规范的RFC有如下几个： RFC7230， RFC7231， RFC7232， RFC7233， RFC7234，RFC7235。 其中RFC7231里的Section 4. Request Methods涉及到了几个HTTP方法，接下来仔细阅读这一章节。

The request method token is the primary source of request semantics; it indicates the purpose for which the client has made this request and what is expected by the client as a successful result.

这里牵涉到一个很重要的词语：semantic 「语义」，那么什么是语义呢？这一篇文章给出了解释：语法和语义的区别。

一种语言是合法句子的集合。什么样的句子是合法的呢？可以从两方面来判断：语法和语义。语法是和文法结构有关，然而语义是和按照这个结构所组合的单词符号的意义有关。合理的语法结构并不表明语义是合法的。例如我们常说：我上大学，这个句子是符合语法规则的，也符合语义规则。但是大学上我，虽然符合语法规则，但没有什么意义，所以说是不符合语义的。

对于HTTP请求来说，语法是指请求响应的格式，比如请求第一行必须是 方法名 URI 协议/版本 这样的格式，具体内容可以参见之前写的《图解HTTP》读书笔记里面的内容，凡是符合这个格式的请求都是合法的。

语义则定义了这一类型的请求具有什么样的性质。比如GET的语义就是「获取资源」，POST的语义是「处理资源」，那么在具体实现这两个方法时，就必须考虑其语义，做出符合其语义的行为。

当然在符合语法的前提下实现违背语义的行为也是可以做到的，比如使用GET方法修改用户信息，POST获取资源列表，这样就只能说这个请求是「合法」的，但不是「符合语义」的。 写到这里突然联想到XML里面的两个概念：Well Formed和Valid，似乎也正是语法和语义的理念呢。

上文说到方法是请求语义的主要来源，也即是还有次要来源，一些请求Header可以进一步修饰请求的语义，比如一个带上了 Range Header的GET请求就变成了部分请求。

RFC7231里定义了HTTP方法的几个性质：

1. Safe - 安全
   这里的「安全」和通常理解的「安全」意义不同，如果一个方法的语义在本质上是「只读」的，那么这个方法就是安全的。客户端向服务端的资源发起的请求如果使用了是安全的方法，就不应该引起服务端任何的状态变化，因此也是无害的。 此RFC定义，GET, HEAD, OPTIONS 和 TRACE 这几个方法是安全的。
   但是这个定义只是规范，并不能保证方法的实现也是安全的，服务端的实现可能会不符合方法语义，正如上文说过的使用GET修改用户信息的情况。
   引入安全这个概念的目的是为了方便网络爬虫和缓存，以免调用或者缓存某些不安全方法时引起某些意外的后果。User Agent（浏览器）应该在执行安全和不安全方法时做出区分对待，并给用户以提示。
2. Idempotent - 幂等
   幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同。按照RFC规范，PUT，DELETE和安全方法都是幂等的。同样，这也仅仅是规范，服务端实现是否幂等是无法确保的。
   引入幂等主要是为了处理同一个请求重复发送的情况，比如在请求响应前失去连接，如果方法是幂等的，就可以放心地重发一次请求。这也是浏览器在后退/刷新时遇到POST会给用户提示的原因：POST语义不是幂等的，重复请求可能会带来意想不到的后果。
3. Cacheable - 可缓存性 顾名思义就是一个方法是否可以被缓存，此RFC里GET，HEAD和某些情况下的POST都是可缓存的，但是绝大多数的浏览器的实现里仅仅支持GET和HEAD。关于缓存的更多内容可以去看RFC7234。

在这三个特性里一直在强调同一个事情，那就是协议不等于实现：协议规定安全在实现里不一定安全，协议规定幂等在实现里不一定幂等，协议规定可缓存在实现里不一定可缓存。这其实就是上面那个作者提到的specification和implementation的关系。

语义之争

走到这一步，其实就明白了要理解这两个方法的区别，本质上是 「语义」的对比而不是「语法」的对比，是「Specification」的对比而不是「Implementation」的对比 。

关于这两种方法的语义，RFC7231里原文已经写得很好了：

The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.

 

The POST method requests that the target resource process the representation enclosed in the request according to the resource’s own specific semantics.

勉强渣翻一下，再加上点自己的理解：

GET的语义是请求获取指定的资源。GET方法是安全、幂等、可缓存的（除非有 Cache-ControlHeader的约束）,GET方法的报文主体没有任何语义。

POST的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST不安全，不幂等，（大部分实现）不可缓存。为了针对其不可缓存性，有一系列的方法来进行优化，以后有机会再研究（FLAG已经立起）。

还是举一个通俗栗子吧，在微博这个场景里，GET的语义会被用在「看看我的Timeline上最新的20条微博」这样的场景，而POST的语义会被用在「发微博、评论、点赞」这样的场景中。