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

程式設計三昧發表於2021-08-03
前端面試HTTP

最近我在做前端面試題總結系列，感興趣的朋友可以新增關注，歡迎指正、交流。

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

HTTP 請求方法

前言

在日常開發中，前端和服務端資料互動時，使用最多的大概就是 HTTP 請求了，今天我們就來總結一下所有的 HTTP 請求方法，並且瞭解一下後臺返回的一些常見狀態碼的含義。

請求方法分類總結

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

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

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

HTTP 請求方法總結

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 方法的內容總結，根據場景合理使用各個方法，可以起到優化效能、增加網路安全的效果。

~

~ 本文完，感謝閱讀！

~

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

大家好，我是〖程式設計三昧〗的作者 隱逸王，我的公眾號是『程式設計三昧』，歡迎關注，希望大家多多指教！

你來，懷揣期望，我有墨香相迎！ 你歸，無論得失，唯以餘韻相贈！

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

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章