HTTP 方法用於指示 API 客戶端希望對給定資源執行的操作。每個 HTTP 方法都對應一個特定的操作，例如創建、讀取、更新或刪除資源，並且每個對 REST API 的請求都必須包含 HTTP 方法。
HTTP 協議的工作原理是客戶端向服務器發送請求，服務器響應這些請求。我們通過使用不同 HTTP 方法（有時稱為 HTTP 動詞）發送 HTTP 請求來執行 CRUD 操作（創建、讀取、更新、刪除）。 GET 和 POST 是最常用的 HTTP 方法，但還有更多 HTTP 方法需要學習。本文將介紹不同的 HTTP 方法以及在構建和使用 Web API 時如何使用它們。
您應該了解的 9 種 HTTP 方法
1. GET 方法
如果我們想從資源（如網站、服務器或 API）檢索數據，我們會向它們發送 GET 請求。例如，如果我們想要客戶列表或特定客戶，我們會向服務器發送 GET 請求。
由於 GET 方法不應該更改資源上的數據，而只是讀取它們（只讀），因此它被認為是安全方法。此外，GET 方法是冪等的。
如何使用 GET 方法測試 API？
當我們想要測試 API 時，我們最常用的方法是 GET 方法。因此，我們期望發生以下情況：
如果資源可訪問，API 將返回 200 狀態代碼，表示“OK”。
除了 200 狀態代碼外，服務器通常還會返回 XML 或 JSON 格式的響應正文。例如，我們期望 [/members] 端點返回 XML 或 JSON 格式的成員列表。
如果服務器不支持該端點，則服務器將返回 404 狀態代碼，表示“未找到”。
如果我們以錯誤的語法發送請求，服務器將返回 400 狀態代碼，表示“錯誤請求”。
2. POST 方法
POST 方法在後端（服務器）創建新的資源。請求正文承載我們想要發送到服務器的數據。它既不是安全方法也不是冪等方法。我們不期望每次發送 POST 請求都能獲得相同的結果。例如，兩個相同的 POST 請求將創建兩個具有相同數據和不同資源 ID 的新的等效資源。
向服務器發送 POST 請求時，我們期望發生以下情況：
理想情況下，如果 POST 請求在另一端創建了一個新的資源，則響應應該帶有 201 狀態代碼，表示“已創建”。
有時，執行 POST 請求不會在給定的 URL 返回資源；在這種情況下，該方法將返回 204 狀態代碼，表示“無內容”。
如何測試 POST 端點
由於 POST 方法創建數據，我們必須謹慎更改數據；強烈建議測試 API 中的所有 POST 方法。此外，請確保在測試完成後刪除已創建的資源。
以下是一些我們可以用來測試使用 POST 方法的 API 的建議：
使用 POST 方法創建一個資源，它應該返回 201 狀態代碼。
執行 GET 方法以檢查是否成功創建了資源。您應該獲得 200 狀態代碼，並且響應應該包含已創建的資源。
使用不正確或格式錯誤的數據執行 POST 方法以檢查操作是否失敗。
3. PUT 方法
使用 PUT 請求方法，我們可以通過將更新後的數據作為請求正文的內容髮送到服務器來更新現有資源。 PUT 方法通過完全替換其全部內容來更新資源。如果它應用於資源集合，它將替換整個集合，因此請小心使用它。服務器在成功更新現有資源後將返回 200 或 204 狀態代碼。
如何使用 PUT 方法測試 API？
PUT 方法是冪等的，它修改整個資源，因此為了測試該行為，我們確保執行以下操作：
多次向服務器發送 PUT 請求，它應該始終返回相同的結果。
當服務器完成 PUT 請求並更新資源時，響應應該帶有 200 或 204 狀態代碼。
服務器完成 PUT 請求後，發出 GET 請求以檢查資源上的數據是否已正確更新。
如果輸入無效或格式錯誤，則不得更新資源。
4. PATCH 方法
PATCH 是另一種不常用的 HTTP 方法。與 PUT 類似，PATCH 更新資源，但它僅部分更新數據，而不是全部更新。例如，為了更精確起見，請求 [PUT] customers/{customerid} 將完全更新資源上 Customers 實體中的字段。但是，PATCH 方法確實會更新客戶實體的提供的字段。通常，此修改應採用標準格式，例如 JSON 或 XML。
如何使用 PATCH 方法測試 API？
要使用 PATCH 方法測試 API，請按照本文中討論的步驟進行操作，以使用 PUT 和 POST 方法測試 API。考慮以下結果：
向服務器發送 PATCH 請求；服務器將返回 2xx HTTP 狀態代碼，這意味著：請求已成功接收、理解和接受。
執行 GET 請求並驗證內容是否已正確更新。
如果請求有效負載不正確或格式錯誤，則操作必須失敗。
5. DELETE 方法
顧名思義，DELETE 方法刪除資源。 DELETE 方法是冪等的；無論調用次數多少，它都返回相同的結果。
大多數 API 總是返回 200 狀態代碼，即使我們嘗試刪除已刪除的資源也是如此，但在某些 API 中，如果目標數據不再存在，則方法調用將返回 404 狀態代碼。
如何測試 DELETE 端點？
在服務器上刪除某些內容時，我們應該謹慎。我們正在刪除數據，這至關重要。首先，確保刪除數據是可以接受的，然後執行以下操作：
調用 POST 方法以創建新的資源。切勿使用實際數據測試 DELETE。例如，首先創建一個新客戶，然後嘗試刪除您剛剛創建的客戶。
對特定資源發出 DELETE 請求。例如，請求 [DELETE] /customers/{customer-id} 刪除具有指定客戶 ID 的客戶。
對已刪除的客戶調用 GET 方法，它應該返回 404，因為資源不再存在。
6. HEAD 方法
HEAD 方法類似於 GET 方法。但它沒有任何響應正文，因此如果它錯誤地返迴響應正文，則必須忽略它。例如，[GET] /customers 端點在其響應正文中返回客戶列表。此外，[HEAD] /customers 也執行相同的操作，但它不返回客戶列表。在請求 GET 端點之前，我們可以發出 HEAD 請求以確定我們正在下載的文件或數據的大小（Content-length）。因此，HEAD 方法是安全且冪等的。
如何測試 HEAD 端點
HEAD 方法的優點之一是，只要 API 支持它，我們就可以測試服務器是否可用和可訪問，並且它比 GET 方法快得多，因為它沒有響應正文。我們期望從 API 獲取的狀態代碼是 200。在每種其他 HTTP 方法之前，我們都可以先使用 HEAD 方法測試 API。
7. OPTIONS 方法
我們使用此方法來獲取有關服務器中給定 URL 的可能的通信選項（允許的 HTTP 方法）的信息，或者使用星號來指代整個服務器。此方法是安全且冪等的。
各種瀏覽器廣泛使用 OPTIONS 方法來檢查目標 API 上的 CORS（跨源資源共享）操作是否受限。
如何測試 OPTIONS 端點
根據服務器是否支持 OPTIONS 方法，我們可以使用 OPTIONS 方法測試服務器的致命故障次數。要嘗試它，請考慮以下幾點：
發出 OPTIONS 請求並檢查返回的標頭和狀態代碼。
測試使用不支持 OPTIONS 方法的資源的失敗情況。
8. TRACE 方法
TRACE 方法用於診斷目的。它使用與客戶端之前發送到服務器的請求正文相同的請求正文創建一個環回測試，並且成功的響應代碼是 200 OK。 TRACE 方法是安全且冪等的。
TRACE 方法可能很危險，因為它可能會洩露憑據。黑客可以使用客戶端攻擊竊取憑據，包括內部身份驗證標頭。
如何使用 TRACE 方法測試 API？
發出標準 HTTP 請求，例如對 /api/status 的 GET 請求
將 GET 替換為 TRACE 並再次發送。
檢查服務器返回的內容。如果響應與原始請求具有相同的信息，則服務器中啟用了 TRACE 功能並且工作正常。
9. CONNECT 方法
CONNECT 方法用於在客戶端和服務器之間建立端到端連接。它在它們之間建立雙向連接，就像隧道一樣。例如，我們可以使用此方法在客戶端和服務器之間安全地傳輸大型文件。
HTTP 方法比較
方法 摘要 CRUD 接受請求正文 冪等 安全 GET 獲取單個資源或資源組 讀取 否 是 是 PUT 一次性更新整個資源 更新 是 是 否 POST 創建新資源 創建 是 否 否 PATCH 部分更新資源 更新 是 否 否 DELETE 刪除資源 刪除 否 是 否 OPTIONS 獲取有關允許的操作的信息 讀取 否 是 是 HEAD 獲取端點的元數據 讀取 否 是 是 TRACE 用於診斷目的 讀取 否 是 是 CONNECT 在客戶端和資源之間建立雙向連接 - 否 - -
以上是HTTP方法和代碼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
