如果你正在學習串接 API，或是使用 n8n、Zapier 這類自動化工具，你一定看過 GET、POST、PUT、DELETE 這些選項。它們到底是什麼意思？為什麼有時候用 GET 會失敗，換成 POST 就可以了？這些看起來像火星文的指令，其實是網路世界溝通的基礎，更是你和 API 之間對話的「動詞」。
想像一下，如果 API 是一間超大的線上餐廳，提供了各式各樣的服務（資料），那 HTTP 請求方法就是你跟服務生溝通的指令。你是要「看菜單 (GET)」、還是要「下一張新訂單 (POST)」、或是「修改訂單內容 (PUT/PATCH)」，甚至是「取消訂單 (DELETE)」？用錯了指令，服務生當然就聽不懂，你的請求自然就會失敗。
搞懂這些「動詞」，你不只可以正確地和 API 溝通，未來在自動化流程除錯時，更能一眼看出問題所在。這篇文章會用最白話的比喻，帶你一次搞懂這些最重要的 HTTP 請求方法，讓你從 API 小白，晉升為能流暢對話的自動化玩家！
什麼是 HTTP 請求方法？跟 API 的關係是？
在解釋各種方法之前，我們要先建立一個共識：網路上的溝通，基本上都是由「客戶端 (Client)」（例如你的瀏覽器或 n8n）向「伺服器 (Server)」發出一個「HTTP 請求 (HTTP Request)」。
HTTP 請求方法 (HTTP Request Methods)，就是這個請求的核心部分，它用來定義你希望伺服器執行的「動作」。簡單來說，它就是網路溝通語言中的「動詞」。
而這跟 API 有什麼關係呢？現今絕大多數的 API，特別是所謂的「RESTful API」，其設計就是完全基於 HTTP 協定。API 開發者會定義好一個個的「資源 (Resource)」(例如：/users 代表所有使用者，/orders/123 代表第 123 號訂單)，然後告訴你，你可以用哪些 HTTP 請求方法來對這些資源進行操作。
所以，學會 HTTP 請求方法，就等於學會了操作絕大多數 API 的基本功。
API 溝通的秘密：一切從「你想做什麼？」開始
想像一下，你走進一家你最愛的咖啡店。這家店就是一個「API 伺服器」，而你（或是你的 n8n 工作流程）就是「客戶端」。你想跟店員（伺服器）互動，你總得先表明你的「意圖」吧？
- 你只是想看看菜單上有什麼？
- 你想要點一杯新的咖啡？
- 你想修改剛剛點的單？
- 還是你決定不買了，想取消訂單？
你看，你的不同「意圖」，決定了你跟店員溝通時使用的「動詞」。而 HTTP 請求方法（Request Methods），就是你在跟 API 溝通時，用來表明你意圖的標準化「動詞」。其中，GET、POST、PUT、DELETE 是最常用、也最重要的四個。
常用 HTTP 請求方法：從 CRUD 到實際應用
在軟體開發中，我們常把對資料的操作歸納為四種基本行為，也就是 CRUD：
- Create (新增)
- Read (讀取)
- Update (更新)
- Delete (刪除)
巧的是，最核心的四個 HTTP 請求方法，正好就對應了這四種行為。用這個框架來理解，你會發現一切都變得非常簡單。
GET：請給我資料！(對應 Read)
GET 是最單純、也最常見的請求方法。它的唯一目的就是向伺服器「獲取」或「讀取」資料，它不應該對伺服器的資料造成任何改變。
- 比喻： 就像走進圖書館，跟館員說：「請給我看《哈利波特》第一集」。你只是想閱讀書本的內容，並不會修改書裡的任何一個字。
- 特性：
- 安全性 (Safe):
GET請求是「安全的」，因為它只讀取資料，理論上不應該有任何副作用（Side Effect），你重複請求一百次也不會改變伺服器上的任何東西。 - 冪等性 (Idempotent):
GET請求是「冪等的」，意思是對同一個 URL 發送一次GET請求和發送一百次，得到的結果應該是完全一樣的。 - 資料傳遞：
GET請求的參數通常會附加在 URL 的尾巴，也就是我們常說的「查詢字串 (Query String)」，例如?id=123&type=user。這也意味著它不適合傳遞敏感資料（例如密碼），因為會直接顯示在網址列上。
- 安全性 (Safe):
- 使用時機：
- 讀取一篇文章的內容。
- 獲取某個使用者的個人資料。
- 請求一個商品列表。
- 基本上，任何「只需要看資料」的場景，都應該使用
GET。
POST：我要新增一筆資料！(對應 Create)
當你需要「新增」一筆全新的資料到伺服器時，就該使用 POST 方法。
- 比喻： 就像你寫好一張新的會員申請表，遞交給櫃檯人員，請他幫你建立一個新的會員檔案。
- 特性：
- 非安全性 (Not Safe):
POST會改變伺服器上的資料（新增了一筆），所以它是不安全的。 - 非冪等性 (Not Idempotent):
POST不是冪等的。如果你連續提交兩次相同的申請表，就會建立「兩個」新的會員檔案。這也是為什麼有時候網頁會提醒你「不要重複提交表單」。 - 資料傳遞：
POST請求的資料是放在「請求主體 (Request Body)」中傳送，不會顯示在 URL 上，因此更適合用來傳送較複雜或敏感的資料。
- 非安全性 (Not Safe):
- 使用時機：
- 使用者註冊新帳號。
- 在論壇上發表一篇新文章或留言。
- 將商品加入購物車（建立一個新的購物車項目）。
- 在 n8n 中，當你想透過 API 在 Google Sheets 新增一列資料時，用的就是
POST。
PUT / PATCH：我要更新現有資料！(對應 Update)
這兩個方法都用於「更新」伺服器上已經存在的資料，但它們之間有一個非常重要且經常被搞混的區別。我剛開始接觸 API 時，也花了好一番功夫才真正搞懂。
- PUT (替換)：
PUT方法代表「完整的替換 (Replace)」。當你使用PUT來更新一筆資料時，你必須提供「完整的」新資料，伺服器會用你給的新資料，完全覆蓋掉舊有的整筆資料。 - PATCH (修改)：
PATCH方法代表「部分的修改 (Modify)」。當你使用PATCH時，你只需要提供「想要修改」的那些欄位即可，其他未提供的欄位將會保持原樣。
用一個超白話的例子來解釋：
假設伺服器上有一筆使用者資料： { "name": "陳小明", "phone": "0912-345678", "email": "ming@email.com" }
現在，我們只想把他的電話改成 "0987-654321"。
- 如果使用
PUT，你必須發送完整的資料：{ "name": "陳小明", "phone": "0987-654321", "email": "ming@email.com" }如果你只發送{ "phone": "0987-654321" }，那麼他的name和email就會被清空！因為PUT是整個換掉。 - 如果使用
PATCH，你只需要發送想改動的資料：{ "phone": "0987-654321" }伺服器收到後，只會更新電話號碼，name和email會維持不變。
結論： 如果 API 有支援 PATCH，通常會是比較方便且安全的更新方式。但並非所有 API 都支援 PATCH，在串接前一定要詳讀 API 文件。
DELETE：我要刪除這筆資料！(對應 Delete)
DELETE 方法的用途就跟它的名字一樣，非常直觀：就是用來「刪除」伺服器上指定的資源。
- 比喻： 告訴圖書館員：「請幫我把這本書從館藏中永久移除」。
- 特性：
- 非安全性 (Not Safe):
DELETE會移除伺服器上的資料，所以它是不安全的。 - 冪等性 (Idempotent):
DELETE是冪等的。刪除一個不存在的資源，跟刪除它一次的結果（資源不存在）是一樣的。重複執行不會造成額外的問題。
- 非安全性 (Not Safe):
- 使用時機：
- 使用者刪除自己的帳號。
- 刪除一篇部落格文章或留言。
- 將商品從購物車中移除。
如何選擇正確的 HTTP 請求方法？一張表格總整理
為了讓你一目了然，我把這些常見的方法整理成一個簡單的表格，你可以把它存下來當作速查表。
| 方法 (Method) | CRUD 對應 | 主要用途 | 安全性 (Safe) | 冪等性 (Idempotent) | 常見範例 |
| GET | Read (讀取) | 從伺服器獲取資料 | ✔️ 是 | ✔️ 是 | 瀏覽網頁、查看商品列表 |
| POST | Create (新增) | 向伺服器提交新資料 | ❌ 否 | ❌ 否 | 註冊帳號、發布新文章 |
| PUT | Update (更新) | 完整替換伺服器上的現有資料 | ❌ 否 | ✔️ 是 | 更新需要提供完整資料的設定檔 |
| PATCH | Update (更新) | 部分修改伺服器上的現有資料 | ❌ 否 | ❌ 否 | 只更新使用者的電話號碼 |
| DELETE | Delete (刪除) | 刪除伺服器上的指定資料 | ❌ 否 | ✔️ 是 | 刪除留言、取消訂單 |
結語：學會 API 的動詞，開啟你的自動化超能力
恭喜你！現在你已經掌握了網路世界最重要的五個「動詞」。GET, POST, PUT, PATCH, DELETE 不再是看不懂的神秘程式碼，而是你和 API 溝通時，精準表達意圖的工具。
理解這些方法的差異，尤其是在自動化流程中，能幫助你避免許多常見的錯誤。例如，當你發現 n8n 流程不斷重複新增資料時，你就會立刻想到，是不是在更新資料的環節誤用了 POST 而不是 PUT 或 PATCH？
這份知識就是你的超能力。下次當你再次打開 n8n、Zapier 或 Postman 時，試著帶著今天學到的觀念去檢視每一個 API 請求的設定。你會發現，你不再只是個操作者，而是一個真正懂得如何與網路世界「對話」的自動化架構師。
