【前端 · 面試 】HTTP 總結（三）—— HTTP 請求方法

這是我參與8月更文挑戰的第3天，活動詳情查看：8月更文挑戰

最近我在作前端面試題總結系列，感興趣的朋友能夠添加關注，歡迎指正、交流。

爭取每一個知識點可以多總結一些，至少要作到在面試時，針對每一個知識點均可以侃起來，不至於啞火。

前言

在平常開發中，前端和服務端數據交互時，使用最多的大概就是 HTTP 請求了，今天咱們就來總結一下全部的 HTTP 請求方法，而且瞭解一下後臺返回的一些常見狀態碼的含義。

請求方法分類總結

根據 HTTP 標準，HTTP 請求可使用多種請求方法。

HTTP1.0 定義了三種請求方法： GET, POST 和 HEAD 方法。

HTTP1.1 新增了六種請求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

GET 方法

GET 是最經常使用的 HTTP 請求方法，會顯示請求指定的資源，並返回響應主體，通常對它的指望是安全且冪等的。

所謂安全是指該操做用於獲取信息而非修改信息。換句話說，GET 請求通常不該產生反作用。就是說，它僅僅是獲取資源信息，就像數據庫查詢同樣，不會修改和增長數據，不會影響資源的狀態。

這裏安全的含義僅僅是指是非修改信息。

冪等的概念簡單點來講，就是指對同一個 URL 的多個請求應該返回一樣的結果。

查詢字符串（名稱/值對）是在 GET 請求的 URL 中發送的，在 URL 後加 ? 鏈接查詢字符串，多條查詢字符串經過 & 來鏈接，好比：

https://cn.bing.com/search?q=%E7%BC%96%E7%A8%8B%E4%B8%89%E6%98%A7&PC=U316&FORM=CHROMN
複製代碼

GET 請求的一些其餘特性：

• GET 請求可被緩存
• GET 請求保留在瀏覽器歷史記錄中
• GET 請求可被收藏爲書籤
• GET 請求不該在處理敏感數據時使用
• GET 請求有長度限制
• GET 請求只應當用於取回數據（不修改）

HEAD 方法

與 GET 方法同樣，都是向服務器發出指定資源的請求，只不過服務器將不傳回資源的本文部分，只返回頭部消息。

它的好處在於，使用這個方法能夠在沒必要傳輸所有內容的狀況下，就能夠獲取其中「關於該資源的信息」（元信息或稱元數據），對資源的首部進行檢查，好比：

• 若是 GET /users 返回用戶列表，
• 那麼 HEAD /users 將發出相同的請求，但不會返回用戶列表。

HEAD 方法的使用場景

• 在不獲取資源的狀況下，瞭解資源的一些信息，好比資源類型；
• 經過查看響應中的狀態碼，能夠肯定資源是否存在；
• 經過查看首部，測試資源是否被修改。

POST 方法

POST 方法用於向指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件），數據被包含在請求本文中。

POST 請求可能會建立新的資源或修改現有資源，或兩者皆有。每次提交，表單的數據被瀏覽器用編碼到HTTP請求的body裏。

瀏覽器發出的POST請求的body的主要格式

• application/x-www-form-urlencoded 用來傳輸簡單的數據，如 "key1=value1&key2=value2" 這樣的格式。
• multipart/form-data 主要用來傳輸文件內容。
• application/json 告訴服務端消息主體是序列化後的 JSON 字符串。
• text/plain 純文本格式

採用 multipart/form-data 是由於 application/x-www-form-urlencoded 的編碼方式對於文件這種二進制的數據很是低效。

除了原生的content-type，開發人員也能夠徹底自定義數據提交格式！

POST 請求的其餘特性：

• POST 請求不會被緩存
• POST 請求不會保留在瀏覽器歷史記錄中
• POST 不能被收藏爲書籤
• POST 請求對數據長度沒有要求

PUT 方法

PUT 方法用於將數據發送到服務器來建立/更新資源。

PUT 與 POST 方法的區別在於，PUT 方法是冪等的：調用一次與連續調用屢次是等價的（即沒有反作用），而連續調用屢次 POST 方法可能會有反作用，好比將一個訂單重複提交屢次。

PUT 方法可能的響應

• 若是目標資源不存在，而且PUT方法成功建立了一份，那麼源頭服務器必須返回 201(Created) 來通知客戶端資源已建立。
• 若是目標資源已經存在，而且依照請求中封裝的表現形式成功進行了更新，那麼，源頭服務器必須返回 200 (OK) 或者 204 (No Content) 來表示請求的成功完成。

DELETE 方法

DELETE 方法就是請求服務器刪除指定 URL 所對應的資源。可是，客戶端沒法保證刪除操做必定會被執行，由於 HTTP 規範容許服務器在不通知客戶端的狀況下撤銷請求。

DELETE 方法可能的響應碼

若是 DELETE 方法成功執行，那麼可能會有如下幾種狀態碼：

• 狀態碼 202 (Accepted) 表示請求的操做可能會成功執行，可是還沒有開始執行。
• 狀態碼 204 (No Content) 表示操做已執行，可是無進一步的相關信息。
• 狀態碼 200 (OK) 表示操做已執行，而且響應中提供了相關狀態的描述信息。

TRACE 方法

TRACE 方法實現沿通向目標資源的路徑的消息「迴環」（loop-back）測試 ，提供了一種實用的 debug 機制。

請求的最終接收者應當原樣反射（reflect）它接收到的消息，做爲一個 Content-Type 爲 message/http 的200（OK）響應的消息的主體（body）返回給客戶端 。

最終接收者是指初始（origin）服務器，或者第一個接收到 Max-Forwards 值爲 0的請求的服務器。

咱們都知道，客戶端在發起一個請求時，這個請求可能要穿過防火牆、代理、網關、或者其它的一些應用程序。這中間的每一個節點均可能會修改原始的 HTTP 請求。因爲有一個「迴環」診斷，在請求最終到達服務器時，服務器會彈回一條 TRACE 響應，並在響應主體中攜帶它收到的原始請求報文的最終模樣。這樣客戶端就能夠查看 HTTP 請求報文在發送的途中，是否被修改過了。

PATCH 方法

在HTTP協議中，請求方法 PATCH 用於對資源進行部分修改。

在HTTP協議中， PUT 方法已經被用來表示對資源進行總體覆蓋， 而 POST 方法則沒有對標準的補丁格式的提供支持。不一樣於 PUT 方法，而與 POST 方法相似，PATCH 方法是非冪等的，這就意味着連續多個的相同請求會產生不一樣的效果。

要判斷一臺服務器是否支持 PATCH 方法，那麼就看它是否將其添加到了響應首部 Allow 或者 Access-Control-Allow-Methods （在跨域訪問的場合，CORS）的方法列表中 。

另一個支持 PATCH 方法的隱含跡象是 Accept-Patch 首部的出現，這個首部明確了服務器端能夠接受的補丁文件的格式。

響應

204 狀態碼錶示這是一個操做成功的響應，由於響應中不帶有消息主體。

OPTIONS 方法

OPTIONS 方法用於獲取目的資源所支持的通訊選項。

客戶端能夠對特定的 URL 使用 OPTIONS 方法，也能夠對整站（經過將 URL 設置爲「*」）使用該方法。

若請求成功，則它會在 HTTP 頭中包含一個名爲 「Allow」 的頭，值是所支持的方法，如 「GET, POST」。

使用示例

可使用 OPTIONS 方法對服務器發起請求，以檢測服務器支持哪些 HTTP 方法，響應報文包含一個 Allow 首部字段，該字段的值代表了服務器支持的全部 HTTP 方法：

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0
複製代碼

CONNECT 方法

CONNECT 方法能夠開啓一個客戶端與所請求資源之間的雙向溝通的通道。它能夠用來建立隧道（tunnel）。

總結

以上就是 HTTP 方法的內容總結，根據場景合理使用各個方法，能夠起到優化性能、增長網絡安全的效果。

~

~ 本文完，感謝閱讀！

~

學習有趣的知識，結識有趣的朋友，塑造有趣的靈魂！

你們好，我是〖編程三昧〗的做者 隱逸王，個人公衆號是『編程三昧』，歡迎關注，但願你們多多指教！

你來，懷揣指望，我有墨香相迎！ 你歸，不管得失，惟以餘韻相贈！

知識與技能並重，內力和外功兼修，理論和實踐兩手都要抓、兩手都要硬！