到目前為止,我們使用過了許多現成的 n8n 節點:Facebook、Google Drive、RSS Read、Discord……
同時,我們也使用過 HTTP Request 節點,達成了一些特殊需求(像是中央氣象署、Supabase、Threads)。你可能是照著文章直接設定就能完成,但你是否想過:這些節點為什麼要這樣設計?如果我想自己動手打造 HTTP Request 節點,該怎麼做?
你可能還會發現一個疑問:如果 n8n 沒有內建節點,我是不是就沒辦法透過工作流完成這個步驟了?
答案當然是 不!
今天,我們要來更加深入了解這個強大的「萬能節點」:HTTP Request。
只要平台提供了 API,且你掌握了閱讀 API 文件的方法,就能自己設計節點,不再受限於 n8n 官方內建了什麼節點。換句話說,你將學會「讀地圖找寶藏」——這可是進階玩家必備的技能。
這部分,可以參考 Day 6 文章中的介紹,以下簡短的為大家複習:
許多網路上的服務(如中央氣象署、YouTube、Google Maps、Facebook)就像是「食材供應商」,各自擁有豐富的資料「食材」。
當你向食材供應商下訂單時,你的意圖很重要:是查詢、下單、更新還是取消?
HTTP 方法 | 用途 | 生活比喻 | 範例 |
---|---|---|---|
GET | 取得資料 | 去市場看看今天有哪些食材 | 取得天氣資料 |
POST | 新增資料 | 下訂單買食材 | 發新貼文 |
PUT / PATCH | 更新資料 | 修改已下的訂單 | 修改貼文 |
DELETE | 刪除資料 | 取消訂單 | 刪除檔案 |
拿到產品型錄(API 文件)後,你不能只說「我要蔬菜」,還要告訴供應商「我要有機、高麗菜、5公斤」。這些額外資訊,就是 Parameters。
Parameters 常見類型:
現在,我們來回頭看看之前的案例,並對照官方文件/ChatGPT:
以中央氣象署API 為例,對照如下圖:
以 Threads 發文為例,官方文件有說明需要有兩步:(1) Create Threads Media Container, (2) Publish Threads Container。官網的文件對照以及我們節點的設定比較如下:
其實一切設定,其實可以從文件中去取得。只要你學會看懂 Method、URL、Parameters,任何 API 都能自己接!
小技巧:用「找關鍵字法」快速定位官方文件中的必要參數(如 Authorization、creation_id 等)。或是也可以利用 ChatGPT 等 AI 工具進行詢問,基本上他回應的都蠻準確的。
目標:透過官方文件,去設計粉專發文的 HTTP Request 節點
n8n 的內建節點,其實就是把這些 API 文件的規則預先封裝成懶人包。
今天,我們更加深入了解「HTTP Request 節點」的設計邏輯。它是 n8n 的萬能鑰匙,只要你懂得看 API 文件,就能打造出任何你想要的自動化功能。從此之後,你不必再受限於「有沒有內建節點」,因為你自己就能造節點!
這幾天我們走過 FB、IG、Threads,今天解鎖自己設定 HTTP Request 節點 —— 這可是整個系列的終極技能之一,你現在幾乎可以自己設計任何節點,開始嘗試各種變化與創意應用!
不過,因為我們這幾天的內容量滿滿、信息量爆表,明天先暫停一下「創造新節點」,來一場「中期回顧」。
這就像看完一部精彩刺激的電影高潮後,先欣賞幕後花絮與導演訪談——整理一下已學會的技能、回顧經典案例,讓你更清楚自己已經會什麼,還能往哪裡去。
我們明天見!