昨天我們開始處理「多筆資料」，了解 n8n 裡的資料不一定只有一筆，也可以利用 Items 和批次處理一次處理很多資料。
但到目前為止，我們使用的資料大部分還是：
自己建立測試資料
Webhook 接收別人傳來的資料
Google Sheets 裡已經存在的資料
這讓我想到一個問題：
如果我想讓 n8n 主動去其他網站或系統取得資料呢？
例如：
查詢天氣資料
取得匯率
查詢商品資訊
呼叫 AI 服務
取得其他系統的資料
這些功能背後常常都會使用到一個東西：
API
所以今天要第一次真正用 n8n 的 HTTP Request Node 呼叫 API。
其實前面 Day 5 就有提過 API，只是當時沒有真的操作。
我現在會把 API 想成：
不同系統之間溝通的方式之一。
例如我有一個天氣服務，而 n8n 想取得天氣資料。
不一定要讓 n8n 打開天氣網站、找到文字再複製回來。
如果這個服務提供 API，就可以直接提出請求：
n8n
↓
API Request
↓
天氣服務
↓
回傳資料
↓
n8n
回傳的資料通常也會是我們前面學過的 JSON。
所以學到這裡，我才發現：
JSON、Webhook、API 其實慢慢都串在一起了。
在 n8n 裡，如果想呼叫一個 API，很常會使用：
HTTP Request Node
它的工作可以簡單理解成：
幫 Workflow 對某個網址發出 HTTP Request，並接收對方回傳的資料。
例如：
Manual Trigger
↓
HTTP Request
↓
API Server
↓
JSON Result
今天先不做需要註冊帳號或 API Key 的服務。
先找一個公開測試 API，專心了解 API 是怎麼運作的。
今天先建立最簡單的流程：
Manual Trigger
↓
HTTP Request
先加入 Manual Trigger。
接著新增一個：
HTTP Request
圖 1 建立 Manual Trigger 與 HTTP Request Node
今天的 Workflow 看起來反而比前幾天簡單很多。
因為今天的重點不是流程有多複雜，而是：
成功跟 n8n 外面的服務取得資料。
今天可以使用 JSONPlaceholder 這類公開測試 API 來練習。
它會提供假的文章、使用者等測試資料，不需要拿自己的私人資料來測試。
例如取得其中一篇測試文章時，可以向它的 /posts/1 資源發出請求。
HTTP Request Node 裡先設定：
Method：GET
再把要取得資料的 API endpoint 填入 URL 欄位。
圖 2 HTTP Request Node 的 GET Request 設定
設定完成後執行 HTTP Request。
如果成功，就會取得類似這種 JSON：
{
"userId": 1,
"id": 1,
"title": "...",
"body": "..."
}
這時候應該會突然有種熟悉的感覺。
因為 Day 8 就已經看過 JSON：
{
"name": "Student",
"course": "AI Automation"
}
只是以前 JSON 是我們自己建立的。
今天則是：
從外部 API 取得 JSON。
圖 3 HTTP Request 成功取得 API 回傳的 JSON 資料
剛剛 HTTP Request 裡設定了：
GET
GET 是常見的 HTTP Method 之一，通常用來向指定的資源取得資料。
可以先簡單理解成：
GET → 我要取得這個資源的資料
例如：
n8n
↓
GET Request
↓
API
↓
Response
除了 GET 之外，以後也很常看到：
POST
PUT
PATCH
DELETE
它們可以用來表示不同的操作。
今天先專心把 GET 搞懂就好。
做到這裡，我開始理解 API 最基本的一組概念：
Request（請求）
Response（回應）
n8n 對 API 說：
「我要取得這筆資料。」
這是：
Request
API 把 JSON 傳回來：
{
"id": 1,
"title": "...",
"body": "..."
}
這就是：
Response
所以今天的資料流可以畫成：
n8n
│
│ Request
↓
API
│
│ Response
↓
n8n
這也是為什麼 n8n 很適合做自動化。
因為取得 Response 之後，可以馬上把資料送到下一個 Node。
既然 API 已經成功取得一篇文章，那就可以把前面學過的 AI 加回來。
Workflow 變成：
Manual Trigger
↓
HTTP Request
↓
AI
例如 HTTP Request 回傳：
{
"userId": 1,
"id": 1,
"title": "...",
"body": "..."
}
AI 就可以使用其中的：
title
body
Prompt 可以寫成：
請閱讀以下文章內容，並整理成簡短摘要。
標題：
{{ $json.title }}
內容：
{{ $json.body }}
請用 2～3 句話整理文章重點。
這時候整個流程就變成：
n8n 主動取得外部資料 → AI 自動處理資料
圖 4 將 HTTP Request 取得的資料交給 AI 處理
如果想把前面學的功能一起用上，還可以再接 Google Sheets：
Manual Trigger
↓
HTTP Request
↓
AI
↓
Google Sheets
最後保存：
| TitleAI Summary | |
|---|---|
| API 取得的文章標題 | AI 產生的摘要 |
這樣就完成一個小型的：
API 資料自動整理 Workflow
整個過程已經完全不需要自己複製文章給 AI。
圖 5 API → AI → Google Sheets 完整 Workflow
做到今天，我一開始很容易把這兩個搞混。
因為它們好像都跟外部資料有關。
但目前可以先這樣理解：
Webhook：
外部系統
↓
傳資料給 n8n
↓
Webhook
比較像：
「我在這裡等你把資料傳進來。」
而今天的 HTTP Request：
n8n
↓
HTTP Request
↓
外部 API
↓
資料回到 n8n
比較像：
「我主動去跟外部服務提出請求。」
這樣兩個就比較不容易搞混。
今天故意選擇不需要 API Key 的測試服務。
但很多真正的 API 不會讓所有人隨便使用。
例如有些服務會要求：
API Key
可以先把它理解成：
API 用來確認呼叫者身分或權限的一種憑證。
所以之後可能會看到：
n8n
↓
HTTP Request
↓
帶著 API Key
↓
API 驗證
↓
回傳資料
有一件事情很重要：
API Key 不應該直接公開在文章或截圖裡。
之後如果截 n8n 畫面，只要看到 API Key、Token、密碼或其他 Credentials，都要先遮掉。
今天也可以故意把 URL 改錯一次。
例如 API 網址錯誤，就可能收到：
404
如果沒有權限，有些 API 可能會回傳：
401
如果伺服器本身發生問題，也可能看到：
500
這些就是常見的 HTTP Status Code。
目前不用全部背起來，可以先記：
2xx → 通常代表請求成功
4xx → 通常是請求端、權限或資源相關問題
5xx → 通常是伺服器端發生問題
這又剛好跟 Day 18 的除錯接起來。
以後 HTTP Request 出錯時，除了看 Node 有沒有變紅，也可以看看 API 回傳的狀態和錯誤資訊。
做到今天，我覺得 n8n 的用途突然又變大很多。
前面比較像是在：
處理已經進入 Workflow 的資料。
但加入 HTTP Request 之後，Workflow 還可以：
主動向其他服務取得資料。
例如未來就可能做到：
Schedule Trigger
↓
每天固定時間
↓
HTTP Request
↓
取得 API 資料
↓
AI 分析
↓
Google Sheets
↓
Email 通知
這樣前面學過的 Schedule Trigger、AI、Google Sheets 和 Email，就又全部可以串回來了。
今天第一次真正使用 HTTP Request Node 呼叫 API。
也理解了幾個重要概念：
API：讓不同系統交換資料與功能的介面
Request：我們送出去的請求
Response：對方回傳的結果
GET：常見的取得資源方式
HTTP Request Node：讓 n8n 呼叫 API
最後把流程從：
Manual Trigger
↓
HTTP Request
進一步變成：
Manual Trigger
↓
HTTP Request
↓
AI
↓
Google Sheets
從 Day 1 只是使用 ChatGPT 問問題，到現在已經開始讓 AI 自動處理從外部服務取得的資料。
但今天使用的是不需要驗證的公開測試 API。
真正開始串接其他服務時，常常會遇到：
API Key、Token、Authentication
所以明天就來繼續處理這個問題。
iThome鐵人賽
看影片追技術