HTTP、方法與 Web API

TL;DR（太長不看） HTTP 是 Web 的語言；它的動詞（方法）就是讓客戶端和伺服器相互理解的語法。選對動詞，傳送正確的請求頭，你的 API 就能運轉自如。無視規則，各種怪問題就會冒出來。本文解釋其中的原因和方法——從原始請求位元組，一直講到 Divooka 中實用的視覺化程式設計工作流。

1. 深入瞭解

我們已經介紹過使用和設計 REST API 的基礎知識。現在我們來深入細節：

• 開發者將瞭解該使用哪種方法（GET、POST 等），以及為什麼。
• 測試人員 / QA 將看到如何在 Postman/Insomnia 風格的節點圖中重現真實世界的流量。
• 非開發人員的團隊成員將對“安全”呼叫與“破壞性”呼叫建立直觀認識（這樣他們就不會再問“我們不能所有地方都用 POST 嗎？”）。

2. HTTP 基礎（10 分鐘複習）

2.1 HTTP 究竟是什麼？

• 一種無狀態、基於文字的請求/響應協議，執行在 TCP 之上（HTTP/3 則執行在 QUIC 之上）。
• 一個連線 → 一個請求 → 一個響應（HTTP/2 中支援多路複用，但概念上是一樣的）。

2.2 三層“三明治”

<Request / Status Line>
<Header 1: value>
<Header 2: value>
...
<BLANK LINE>
<Optional Body>

那個空行（\r\n\r\n）就是祕訣所在：它告訴所有人“請求頭結束了，正文開始了”。

2.3 理解：安全性 • 冪等性 • 可快取性

在使用 HTTP 方法時，瞭解三個影響請求行為的關鍵屬性會很有幫助——尤其是在你構建流程、重試操作或快取響應的時候。

🔹 安全方法

這些方法是只讀的——它們不會更改伺服器上的任何內容。你可以隨意多次呼叫，而沒有任何風險。

• 示例： GET、HEAD、OPTIONS
• 用途： 安全方法非常適合預取或檢查資料，不會產生副作用。

🔹 冪等方法

這些方法可能會更改內容，但執行多次與執行一次的效果相同。

• 示例： GET、PUT、DELETE、HEAD、OPTIONS
• 用途： 非常適合重試——如果網路故障導致請求被重複傳送，你也不會意外地建立或刪除多個物件。

🔹 可快取方法

對於這些方法，響應可以由瀏覽器或代理伺服器安全地儲存（快取）。

• 示例： GET（最常見），有時也包括 HEAD
• 用途： 避免為相同的資料重複呼叫，讓你的應用更快、更輕量。

快速總結：

屬性	含義	常見方法
安全	不更改資料	GET、HEAD、OPTIONS
冪等	無論傳送多少次，結果都相同	GET、PUT、DELETE、HEAD、OPTIONS
可快取	響應可以被儲存以便複用	GET（預設）、HEAD

3. 原始 HTTP 訊息格式（純文字示例）

檢視原始文字對我們有以下幫助：

• 瞭解真實情況： Divooka 中所有好用的“HTTP Request”節點，最終都會轉換為通過 TCP 傳送的純文字流（外加 \r\n 分隔符）。
• 強大的除錯能力： 當出現問題時（例如請求頭拼寫錯誤或缺少空行），閱讀原始訊息可以幫助你準確找出問題所在。
• 學習的橋樑： 檢視原始文字可以加深你對“請求行 → 請求頭 → 空行 → 正文”如何對應到我們的視覺化工具底層行為的理解。

3.1 原始 HTTP 請求剖析

示例：一個取得 JSON 資源的簡單 GET 請求

GET /api/users/123 HTTP/1.1
Host: api.example.com
Accept: application/json
User-Agent: Divooka/1.0
Authorization: Bearer <token>

逐行解析：

1. GET /api/users/123 HTTP/1.1
   • 請求行： <METHOD> <PATH> <HTTP-VERSION>。
   • 這裡，GET 請求取得 ID 為 123 的使用者。
   • HTTP/1.1 告訴伺服器我們使用的是哪個版本的協議。
2. Host: api.example.com
   • 在 HTTP/1.1 中是必需的，以便伺服器知道你要存取的是哪個虛擬主機——當一臺伺服器託管多個域名時，這一點尤其重要。
3. Accept: application/json
   • “請返回 JSON。”如果省略，伺服器通常會預設返回 HTML 或它自己的預設格式。
4. User-Agent: MyVisualTool/1.0
   • 標識客戶端。Postman 或 Divooka 會傳送類似 PostmanRuntime/7.28.4 的值。
5. Authorization: Bearer <token>
   • 傳送 JWT 或 OAuth 2.0 令牌的常用方式。
6. （空行）
   • CRLF CRLF 分隔符： 兩個連續的 \r\n 序列標誌著請求頭的結束。如果沒有它，伺服器會一直等待更多的請求頭行！
7. （後面沒有正文，因為 GET 通常不傳送正文。）

3.2 原始 HTTP 響應剖析

示例：伺服器對該 GET 請求的響應

HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 14:35:22 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 111
Cache-Control: no-cache, no-store
ETag: "5f4dcc3b..."

{
  "id": 123,
  "name": "Alice",
  "email": "alice@example.com",
  "created_at": "2025-05-20T08:15:00Z"
}

注意 Content-Length 必須等於 111 位元組（即 JSON 負載的確切長度）。如果伺服器使用 chunked（分塊）編碼以流式方式傳送，它會省略 Content-Length，轉而傳送帶有大小字首的資料塊。

逐行解析：

1. HTTP/1.1 200 OK
   • 狀態行： <HTTP-VERSION> <STATUS_CODE> <REASON_PHRASE>。
   • 這裡，200 OK 的意思是“成功，這是負載”。
2. Date: Mon, 02 Jun 2025 14:35:22 GMT
   • 伺服器的時鐘。當你需要比較時間戳請求頭或除錯超時問題時很有用。
3. Content-Type: application/json; charset=utf-8
   • 告訴客戶端如何解釋正文。如果你的 Divooka 流程期望的是 text/html，你就會知道哪裡出了問題。
4. Content-Length:1117
   • 隨後正文的確切位元組長度。如果沒有它（或分塊編碼），客戶端將無法知道正文在哪裡結束。
5. Cache-Control: no-cache, no-store
   • 指示中間方（瀏覽器、CDN）不要快取此響應。
6. ETag: "5f4dcc3b5aa765d61d8327deb882cf99"
   • 資源這一特定版本的識別符號。之後，客戶端可以在 GET 請求中傳送 If-None-Match: "<etag>" 來檢查資料是否已更改。
7. （空行）
   • 表示“請求頭結束了”。接下來的位元組屬於正文。
8. 正文： 原始 JSON 負載，長度恰好為 97 位元組（包括空白字元和換行符號）。

{
"id": 123,
"name": "Alice",
"email": "[alice@example.com](mailto:alice@example.com)",
"created\_at": "2025-05-20T08:15:00Z"
}

3.4 傳送帶 JSON 正文的原始 POST 請求

下面是一個更詳細的示例，展示帶有 JSON 負載的 POST /contacts 在純文字中是什麼樣子。請注意，Content-Length 請求頭必須與正文的位元組數一致（包括花括號、引號和換行符號）。

POST /api/contacts HTTP/1.1
Host: api.example.com
User-Agent: MyVisualTool/1.0
Content-Type: application/json
Content-Length:  84
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...

{
  "first_name": "Bob",
  "last_name": "Smith",
  "email": "bob.smith@example.com"
}

• 請求頭部分： • 前五行都是請求頭或請求行。 • 空行之後的所有內容都是正文。 • 伺服器在該空行之後恰好讀取 84 個位元組——不多也不少。
• 正文部分： • JSON 負載在語法上必須有效（逗號、引號、花括號都要正確配對）。 • 如果你不小心輸入了 Contnt-Length: 85，伺服器會多等待一個位元組，或者可能拒絕你的請求。

3.5 “分塊”傳輸編碼是什麼樣子

有些伺服器會把較大的正文分成多段（“塊”）傳送，這樣就不需要預先知道 Content-Length。分塊響應看起來是這樣的：

HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 15:00:00 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked

1f      <– hex length of first chunk: 31 bytes
{"page":1,"per_page":10,"total":42}
2a      <– hex length of next chunk: 42 bytes
{"data":[{"id":1,...},{"id":2,...},...]}
0       <– “0” means “no more chunks”

• 分塊編碼的工作方式：
  1. 伺服器傳送一個十六進位制數（例如 1f），後跟 \r\n。這告訴你“接下來有 31 個位元組”。
  2. 然後是接下來的 31 個位元組資料（例如那個小 JSON 物件），後跟 \r\n。
  3. 然後是另一個十六進位制數（2a = 42 位元組），依此類推。
  4. 最後的 0\r\n\r\n 表示“全部傳送完畢，謝謝”。
• 分塊編碼為什麼重要： • 你的 Divooka “HTTP Request”節點通常會隱藏這些細節，但如果你使用純文字的“Raw Socket”節點，就會看到這些資料塊一一傳過來。 • 分塊響應不包含 Content-Length 請求頭。客戶端必須不斷重組資料塊，直到遇到長度為零的塊為止。

3.6 常見陷阱

失誤	症狀	解決方法
忘記空行	立即返回“400 Bad Request”	在請求頭之後新增 \r\n\r\n
Content-Length 錯誤	連線掛起或內容被截斷	讓你的客戶端/工具來計算它
換行符號混用（只有 \n）	部分伺服器會拒絕	在原始模式下始終使用 \r\n

4 CRUD 與 HTTP 方法

CRUD 代表：

• Create（建立）：新增新的記錄或資源（例如建立使用者賬戶）。
• Read（讀取）：檢索或檢視現有資料（例如取得使用者的個人資料）。
• Update（更新）：修改現有資料——要麼完全替換，要麼只更改某些欄位。
  • 整體更新替換整個資源。
  • 部分更新只更改指定的欄位。
• Delete（刪除）：從系統中移除記錄或資源。

CRUD	典型方法	為什麼這樣搭配
Create	POST	非冪等；由伺服器選擇新的 URI
Read	GET（或 HEAD）	安全且可快取
Update-whole	PUT	冪等的完整替換
Update-partial	PATCH	冪等的欄位級更改
Delete	DELETE	冪等的刪除

4.1 當 CRUD 不適用時

• 登入/登出——POST /auth/login、POST /auth/logout
• 複雜操作——POST /payments/{id}/capture
• 批量操作——POST /users/bulk_delete，附帶一個由 ID 組成的 JSON 陣列

5 逐個方法詳解

下面的每一節都遵循相同的結構：

語義 • 冪等性 / 安全性 • 典型狀態碼 • Divooka 示例 • 常見陷阱

5.1 GET

• 安全 + 冪等 + 可快取
• 狀態碼 200 OK、304 Not Modified。
• Divooka：拖入一個 Send (HTTP) Request 節點 → Method = GET → URL = {{base}}/users?active=true → 連線到 Preview JSON。
• 陷阱：不要在 GET 中修改資料（“這只是一個無害的跟蹤像素！”……直到廣告攔截器刪掉你一半的資料庫）。

5.2 POST

• 建立或處理；預設不是冪等的。
• 狀態碼 201 Created（新的 URI 位於 Location 請求頭中）或 200 OK。
• Divooka：新增一個 Text 或 (YAML) To JSON 節點，選擇 POST /users，正文為 {"name": "Bob"}。
• 陷阱：在緩慢的 Wi-Fi 上重複提交付款表單 → 被扣款兩次。請使用 Idempotency-Key 請求頭或在後端去重。

5.3 PUT

• 對給定 URI 處的資源進行完整替換。冪等。
• 狀態碼 200 OK（有正文）、204 No Content（無正文）。
• Divooka：對 /users/123 傳送 PUT 請求，附帶完整的使用者物件（JSON 格式）。
• 陷阱：只傳送已更改的欄位——伺服器會把缺失的欄位覆蓋為 null。

5.4 PATCH

• 部分更新；如果實現合理，則是冪等的。
• 正文可以是“merge patch”（只包含已更改的欄位），也可以是 RFC 6902 JSON Patch。
• Divooka：使用 Text 節點編寫部分 JSON → 對 /users/123 傳送 PATCH 請求，正文為 {"email": "new@x.com"}。
• 陷阱：客戶端和伺服器對補丁格式的理解不一致 → 415 Unsupported Media Type。

5.5 DELETE

• 刪除資源；冪等。
• 狀態碼 204 No Content（成功）、404 Not Found（已不存在）。
• Divooka：使用 DELETE 的 Send Request 節點 → 把狀態碼傳入 Branch：如果是 204，顯示“已刪除”，否則記錄錯誤。
• 陷阱：未經身份驗證的刪除（糟糕！）。

5.6 HEAD

• 類似 GET，但只返回響應頭。
• 用於探測資源是否存在或取得後設資料（Content-Length、Last-Modified）。
• Divooka：對 /videos/intro.mp4 傳送 HEAD 請求 → 如果 Content-Length > 10 MB，則改為流式傳輸縮圖。

5.7 OPTIONS

• “我在這裡能做什麼？”——返回 Allow 響應頭和 CORS 規則。
• 對瀏覽器的預檢請求（Access-Control-Request-Method）至關重要。
• Divooka：對 /users 傳送 OPTIONS 請求 → 解析 Allow，動態啟用/禁用按鈕。
• 陷阱：伺服器忽略 OPTIONS → 跨域 JS 就要哭了。

5.8 較少見的方法（TRACE、CONNECT、自訂方法）

• TRACE——回顯請求（用於除錯；通常被禁用）。
• CONNECT——隧道（通過代理傳輸 TLS）。
• 自訂方法——例如 WebDAV 的 PROPFIND、REPORT。Divooka 可以在方法欄位中傳送任意標記。

6. 狀態碼及其“夥伴”

狀態碼	動詞	含義	Divooka 提示
200 OK	GET/PUT/PATCH	成功，有正文	在 JSON 檢視器中檢視
201 Created	POST	資源已建立；見 Location	將響應頭提取到變數中
204 No Content	PUT/PATCH/DELETE	成功，無正文	跳過 JSON 解析
301/302	任意	重定向，會改變 GET/POST 規則	自動跟隨？在節點中切換
307/308	任意	重定向，保留方法	適用於 PUT → PUT
400	任意	語法/正文錯誤	顯示錯誤提示
401/403	任意	身份驗證失敗 / 禁止存取	重新整理令牌邏輯
404	任意	未找到	重試？可能沒用
405	任意	方法不被允許	你選錯了動詞
500/503	任意	伺服器故障 / 過載	新增重試/退避迴圈

7 最佳實踐與常見陷阱

1. 選擇正確的動詞——代理、快取、SDK 生成器都依賴於它。
2. 設定 Content-Type 和 Accept——自動檢測只是個神話。
3. 對有風險的 POST 請求（付款、註冊）使用冪等鍵。
4. 處理 CORS——如果瀏覽器會呼叫你的服務，就要支援 OPTIONS。
5. 禮貌地為 API 做版本管理——通過路徑（/v2/users）或請求頭（Accept-Version），不要在半途中給方法賦予額外的含義。
6. 保護破壞性的動詞——PUT/PATCH/DELETE 要求身份驗證。
7. 安全地並行化——GET 可以併發執行；而針對同一資源競爭的兩個 PUT 應當序列執行或使用 ETag。

8 高階主題（可選，供提前閱讀）

• HATEOAS——響應中包含後續可執行的操作（帶有方法提示的 _links）。
• 條件請求——使用 If-None-Match、If-Match 節省頻寬並避免更新丟失。
• HTTP/2 多路複用——一個連線中可以有多個請求；方法保持不變。
• GraphQL 與 REST——所有請求都是 POST，但快取轉而依賴查詢雜湊。
• Webhook——它們只是反方向的 POST；設計接收方時，請遵循你對客戶端所期望的同樣的動詞規範。

9 融會貫通：端到端示例場景

下面是三個貼近實際的工作流，每個都拆分為清晰的步驟，展示不同的 HTTP 方法如何在單個流程中協同工作。可以把每一步看作 Divooka 中的一個節點：你選擇的方法決定了接下來會發生什麼。在這些場景之後，我們會簡要看看如何把其中一個場景對映為一個簡單的視覺化管道。

9.1 場景 A：使用者註冊流程

假設一位新使用者正在你的網站上註冊。你需要防範跨站攻擊、建立賬戶、確認對方的電子郵件，最後讓對方更新個人資料。整個過程如下：

1. 取得 CSRF 令牌（GET /csrf-token）。 首先，客戶端傳送一個 GET /csrf-token 請求。伺服器在正文中返回一個令牌（例如 { "csrf_token": "abc123" }）。在 Divooka 中，這可能是一個 GET 節點，連線到一個“儲存令牌”節點，後者把 csrf_token 儲存到一個變數中。

2. 提交登錄檔單（POST /register）。 接下來，客戶端傳送一個 POST /register 請求，正文為類似下面的 JSON：

   {
     "username": "jane_doe",
     "email": "jane@example.com",
     "password": "s3cur3",
     "csrf_token": "abc123"
   }
   

   如果一切有效，伺服器會返回狀態碼 201（Created），可能還會附帶一條“請驗證你的電子郵件”的訊息。在 Divooka 中，你會使用一個 POST 節點，帶上 X-CSRF-Token 或將其放入 JSON 中，然後把響應路由到一個“檢查狀態”節點。如果是 201，就繼續；如果是 400，就顯示錯誤。

3. 輪詢電子郵件驗證狀態（GET /verify?token=…）。 註冊之後，使用者點選電子郵件中的連結（類似 /verify?token=xyz）。客戶端可以通過反覆傳送 GET /verify?token=xyz 來模擬輪詢。每次，伺服器可能會這樣回覆：

   • 在使用者點選真正的連結之前，回覆 200 OK { "verified": false }
   • 使用者點選之後，回覆 200 OK { "verified": true } 在 Divooka 中，你可以使用一個迴圈：由一個 GET 節點檢查 response.body.verified；如果為 false，等待幾秒後重試（最多重試一定次數）；如果為 true，則繼續。

4. 更新新使用者的個人資料（PATCH /users/）。 賬戶驗證通過後，客戶端傳送 PATCH /users/123（假設伺服器返回了 id = 123），正文例如：

   { "display_name": "Jane Doe", "avatar_url": "https://..." }
   

   這個部分更新讓使用者可以個性化自己的賬戶。伺服器返回 200 OK 以及更新後的使用者物件。在 Divooka 中，一個 PATCH 節點讀取已儲存的 id 併傳送 JSON 補丁。如果成功，就顯示“歡迎，Jane！”；如果失敗，錯誤處理程式就會介入。

9.2 場景 B：庫存管理

假設你經營一個電子商務網站，需要讓倉庫資料保持同步。你希望列出所有商品、更新庫存數量、刪除已售罄的產品，並批量新增新產品。下面是一種直接的做法：

1. 取得目前商品（GET /items）。 客戶端傳送 GET /items，伺服器返回一個 JSON 陣列：

   [
     { "id": 101, "name": "Widget A", "quantity": 5 },
     { "id": 102, "name": "Widget B", "quantity": 0 },
     { "id": 103, "name": "Widget C", "quantity": 12 }
   ]
   

   在 Divooka 中，一個 GET 節點連線到一個“For Each”節點，後者遍歷 response.body 中的每個商品。

2. 在需要時更新數量（PUT /items/）。 對於任何庫存發生變化的商品——例如 Widget A 從 5 變為 3——你傳送：

   PUT /items/101
   {
     "id": 101,
     "name": "Widget A",
     "quantity": 3
   }
   

   在 Divooka 中，每次迴圈迭代都會檢查 quantity 是否需要調整；如果需要，就呼叫一個 PUT 節點，並傳入完整的商品物件。成功後，伺服器回覆 200 OK 或 204 No Content。

3. 刪除已售罄的商品（DELETE /items/）。 如果 quantity 為 0（比如 Widget B），客戶端就傳送 DELETE /items/102。伺服器回覆 204 No Content，表示“商品已刪除”。在 Divooka 中，同一個 For Each 迴圈中可以包含一個條件判斷：如果 quantity == 0，就呼叫 DELETE 節點；否則跳過。

4. 批量新增新商品（POST /items/bulk）。 最後，要一次新增多個新產品，只需傳送一個請求：

   POST /items/bulk
   {
     "items": [
       { "name": "Widget D", "quantity": 20 },
       { "name": "Widget E", "quantity": 15 }
     ]
   }
   

   伺服器返回 201 Created 以及新 ID 的列表：

   { "created": [ { "id": 104 }, { "id": 105 } ] }
   

   在 Divooka 中，這隻需要一個 POST 節點，再配合一個遍歷你的“newItems”列表的 JSON Builder。成功之後，你可以記錄一份摘要，或者顯示一條“批量新增完成”的訊息。

9.3 場景 C：自動化錯誤處理與重試邏輯

當服務繁忙時，你不希望整個流程崩潰。相反，應當通過重試來處理 503 Service Unavailable，如果仍然失敗再發出警報。下面是一個簡單的模式：

1. 初始請求（GET /health-check）。 首先傳送 GET /health-check。伺服器通常返回 200 OK { "status": "healthy" }。在 Divooka 中，把響應路由到一個檢查 statusCode 的“Switch”節點。

2. 如果遇到 503，暫停後重試。 如果 statusCode == 503，使用一個設定為 5000 毫秒（5 秒）的“Delay”節點，然後迴圈回到同一個 GET 節點。記錄重試次數——嘗試 3 次後停止。在 Divooka 中，這可能是一個小的子流程，其中有一個變數 retryCount，每次遇到 503 時遞增。

3. 如果重試後仍然失敗，傳送警報（POST /alerts）。 當 retryCount 達到 3 而你仍然收到 503 時，轉到一個 POST /alerts 節點，正文為：

   {
     "message": "Health check still failing after 3 retries.",
     "timestamp": "2025-06-02T15:00:00Z"
   }
   

   伺服器回覆 201 Created。在 Divooka 中，你可以把它連線到一個“Notification”節點，通過電子郵件傳送或記錄該問題。

4. 只要有一次 GET 成功（200），就繼續正常流程。 一旦從 GET /health-check 收到 200 OK，就跳出重試，繼續執行其他任務（例如定時資料取得或關鍵更新）。在 Divooka 中，這只是 Switch 節點針對 statusCode == 200 的另一個分支。

9.4 示例管道示意圖（過程式上下文）

下面粗略展示了場景 B 在 Divooka 中可能的樣子。每個方框代表一個節點，箭頭表示資料流。每個節點中的方法（GET/PUT/DELETE/POST）決定了你是在取得、更新、刪除還是建立資料。

[Start]
   ↓
[GET /items]            ← Fetch list of items
   ↓
┌───────────────┐
│For Each item │────────────────────────────────────────────────────╮
└───────────────┘                                                │
   ↓                                                            │
[Check quantity]                                                │
   ↓                                                            │
[quantity > 0?] ─ No─▶[DELETE /items/{id}] ──→(Log “Deleted”)   │
   ↓ Yes                                                        │
[quantity changed?] ─ No─▶(Skip update)                         │
   ↓ Yes                                                        │
[PUT /items/{id}] ──→(Log “Updated”)                            │
   ↓                                                            │
   ⤵─────────────────────────────────────────────────────────────────┘
   ↓
[Collect results]
   ↓
[POST /items/bulk]   ← Add new items
   ↓
[Show “Done” Message]
   ↓
[End]

1. GET /items 節點取得所有商品。
2. 對響應中的每個商品進行迴圈（For Each item）。
3. 一個 Decision 節點檢查是否 quantity == 0。
   • 如果是，呼叫 DELETE /items/ 並記錄成功。
   • 如果不是，檢查 quantity 是否發生了變化。
     • 如果有變化，呼叫 PUT /items/ 進行更新並記錄。
     • 否則什麼也不做，繼續下一個。
4. 迴圈結束後，管道收集你想要新增的所有新商品，並以一個批次傳送 POST /items/bulk。
5. 最後，一個節點顯示“Done”或寫入日誌。

實踐要點

• 你可以看到每個 HTTP 方法如何各司其職——只在 quantity == 0 時使用 DELETE，只在需要更改時使用 PUT，只在批量建立時使用 POST。
• Divooka 的視覺化模型讓這些分支和迴圈變得直觀：你只需拖放新增一個判斷節點，選擇你的變數（比如 quantity），然後連線即可。
• 結合場景 C 中的 Switch、Delay 和重試計數器，你可以優雅地處理錯誤：重試幾次，然後發出警報。

把這些示例當作範本來使用。換成你自己的端點，調整請求頭，讓 Divooka 來完成插入正確的空行、計算 Content-Length、路由成功與失敗路徑等繁重工作。需要除錯時，可以逐步進入程式流程檢視中間結果，或者使用底層節點並貼上確切的 HTTP 文字，觀察請求頭和正文是如何在網路上傳輸的。

10 速查參考

方法	安全	冪等	成功狀態碼	典型用途
GET	✔	✔	200, 304	讀取資料
HEAD	✔	✔	200	讀取響應頭
POST	✘	✘	201, 200	建立 / 操作
PUT	✘	✔	200, 204	替換資源
PATCH	✘	✔	200, 204	部分更新
DELETE	✘	✔	204, 200	刪除資源
OPTIONS	✔	✔	200	能力探測 / CORS

11 關鍵要點

• HTTP 在網路上傳輸的只是文字——掌握原始格式，你就能除錯任何問題。
• 方法的選擇會影響快取、重試、安全，甚至在按請求計費的方案中影響費用。
• Divooka（或任何其他工具）會自動處理請求頭、空行和 Content-Length，但瞭解底層原理能讓你從使用者變成高手。
• 拿不準時：GET 用於讀取，POST 用於建立，PUT/PATCH 用於更新，DELETE 用於刪除。 如果你要打破這條規則，請給出有文件記錄的理由。

後續步驟

1. 啟動 Divooka，建立一個名為 “Method Playground” 的新工作區文件
2. 重建上面的示例——切換到原始模式，觀察傳輸的位元組。
3. 試著在 POST 請求中新增一個 Idempotency-Key 請求頭，然後按一下“Run”五次。記下你的伺服器做了什麼。
4. 收藏本文。將來那個盯著一個莫名其妙的 405 發呆的你會感謝你的。

參考資料

• 知識庫中關於 REST API 的文章。
• Divooka Web API 測試示例。