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

程式設計三昧發表於2021-08-03

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

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

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 協議》,轉載必須註明作者和本文連結

相關文章