HTTP 方法：GET 和 POST 的区别对比

男娘i 2022-12-02 13:55 189阅读 0赞

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

**因为讨论到接口发送json报文的方法，说 POST 方法无长度限制，而我对此一无所知，所以学习一下请求发送的两种方法。（这里重点讨论接口的get和post方法，不介绍浏览器的这两种方法。）**

**没学过计算机原理，伤不起呀~**

--------------------

## 比较 GET 与 POST ##

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

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

--------------------

## 什么是 HTTP？ ##

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。超文本传输协议（HTTP）的设计目的是保证客户机与服务器之间的通信。

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

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

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

HTTP请求数据:

![format_png][]

HTTP响应数据:

![format_png 1][]

--------------------

## 两种 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: quentinne.com
    name1=value1&name2=value2

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

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

--------------------

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。

*  GET的语义是**请求获取指定的资源**。GET方法是安全、幂等、可缓存的（除非有 Cache-ControlHeader的约束）,GET方法的报文主体没有任何语义。
 *  POST的语义是**根据请求负荷（报文主体）对指定的资源做出处理**，具体的处理方式视资源类型而不同。POST不安全，不幂等，（大部分实现）不可缓存。为了针对其不可缓存性，有一系列的方法来进行优化。

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

[format_png]: /images/20221123/f2710e03749945f5919e1d00ae4db440.png
[format_png 1]: /images/20221123/dd817d6457884fd48b077f5c1e724628.png