聊聊 HTTP 常見的請求方式

在互聯網已經滲透了生產、生活各個角落的今天，人們能夠登陸微信語音聊天，能夠隨手「掃」到各類功能的二維碼，能夠經過方便快捷的無人超市購物……這種互聯網領域的跨越式發展，不只知足了人們生活中各類各樣的需求，也催生了一個個新興領域的誕生，爲經濟增加註入了強勁動力。

上網的過程，實際上是瀏覽器向服務端發送請求，以後將服務端主機上的內容顯示到本地的一個流程。而瀏覽器與服務器之間的請求走的就是 HTTP 協議。

自 1990 年以來，超文本傳輸協議（HTTP） 就成爲了互聯網數據通訊的基礎，它是分佈式協做超媒體信息系統的應用層協議，是一種通用的無狀態協議。具體來說就是讓服務器不保留與客戶交易時的任何狀態，由客戶端單方面向服務器發送請求數據。

HTTP 主要有 0.九、1.0、1.一、2.0 版本，其中 1.1 版本定義了 9 種 Method（方法），分別是：

這些方法中，最多見的即是 GET 和 POST，可是可能不多有人關注二者都有什麼做用，咱們一塊兒來看一看吧。

GET vs POST Method

GET 和 POST 都是 HTTP 協定的一種請求標準，一樣基於 TCP 傳輸層協議。二者主要區別在存放數據的方式不一樣，進而形成的傳輸量、安全性等差別。

GET

咱們先來看一下 GET 是怎麼傳送信息的：

<form method="get" action="">
<input type="text" name="id" />
<input type="submit" />
</form>

如上完成代碼點擊「提交」以後，瀏覽器的網址就會變成 http://www.a.com/a.html?id=11111，瀏覽器會自動將表單內容轉爲 Query String 加在 URL 後面進行請求。這樣，從瀏覽器的網址裏就能夠看見表單要傳送的資料。

POST

接下來咱們看看 POST 的傳送：

<form method="post" action="">
<input type="text" name="id" />
<input type="submit" />
</form>

提交以後，地址並沒有變化，可是經過查看 HTTP Request 的內容能夠發現，POST 是將表單資料放在 Message Body 進行傳送。

看不太懂代碼的小夥伴也不要着急，咱們以現實生活中寄信的機制來舉例。若是說信封的撰寫格式是 HTTP，咱們能夠將信封外的內容稱爲 Http-Header，信封內的書信稱爲 Message Body。 HTTP Method 就是你要告訴郵差的寄信規則。

而假設 GET 就如同明信片同樣將要傳遞的信息寫在信封（Http-Header）上，是信封內不裝信件的寄送方式，是直接將要傳送的信息以 Query String（一種 Key/Vaule 的編碼方式）的形式加在地址（URL）後面進行傳送。那 POST 就是信封內裝有信件的寄送方式，不但信封能夠寫東西，信封內（Message Body）還能夠放入你想要寄送的其餘資料，以後由郵差進行傳送。

GET VS POST

整體來講，兩種請求方式有以下區別：

- 傳遞參數方式：GET 是將參數寫在 URL 中 ? 的後面，並用 & 分隔不一樣參數；而 POST 是將信息存放在 Message Body 中傳送。

- 傳輸資料量限制：HTTP 協定自己沒有限制 URL 及正文長度，多半是瀏覽器爲了不過長的 URL 消耗過多的資源而限制長度；而以 POST 請求一般都沒有內容長度限制的問題。

- 安全性問題：GET 請求方式從瀏覽器的 URL 地址就能夠看到參數；但不管是 GET 仍是 POST 其實都是不安全的，由於 HTTP 協定是明文傳輸，只要攔截封包便能輕易獲取重要資訊。想要安全傳輸資料，必須使用 SSL/TLS來加密封包，也就是 HTTPS。

除了咱們較爲常見的 GET 和 POST 兩種請求方式，如今其餘請求方式也愈來愈多的被使用。例如又拍雲基於 RESTful 架構的 REST API 中，除了使用 GET 獲取文件外，也會使用 PUT 來上傳文件，DELETE 用來刪除文件，HEAD 用來獲取文件信息，使用 PATCH 來修改文件 Metadata 信息等等。

請求與狀態碼

固然，上面講的請求方式雖然很常見，可是若是不是稍微有些瞭解或者對互聯網有些關注的小夥伴，可能並不會注意到。可是咱們接下來講的確定是你們都有見過的。畢竟在咱們使用網頁瀏覽內容的過程當中確定，有見到過例如：404 NOT FOUND、504 TIME OUT，這類的提示。其實這個是 HTTP 的狀態碼。

HTTP 狀態碼由三個十進制數字組成，第一個十進制數字定義了狀態碼的類型，後兩位不具備任何分類做用。當用戶訪問一個網頁時，用戶的瀏覽器會向網頁所在服務器發出請求。在瀏覽器接收並顯示網頁前，此網頁所在的服務器會返回一個包含 HTTP 狀態碼的信息頭（Header）用以響應瀏覽器的請求。而這個狀態碼則能夠幫助咱們粗略的判斷請求結果或錯誤緣由。

HTTP 狀態碼共分爲 5 種類型：

一直在使用又拍雲 CDN 的小夥伴兒對一些常見的狀態碼確定很熟悉。好比，網站訪問成功請求會返回 200；開啓了強制 HTTPS，會返回 301；若是開啓了防盜鏈被攔截，則是返回 403 等等。

在這些常規的狀態碼下，又拍雲還進行了進一步的封裝，讓咱們能夠經過查詢又拍雲錯誤碼錶的方式得到更爲準確的網站報錯緣由。

{"code":"40310013","msg":"invalid user token."}

查詢錯誤碼錶得知，觸發了 Token 防盜鏈規

講了這麼多，是否是對 HTTP 請求有了更近一步的瞭解？固然了，HTTP 協議不只僅於此，有興趣的小夥伴兒們要持續關注哦~

推薦閱讀

QUIC協議詳解之Initial包的處理

當我談 HTTP 時，我談些什麼?