n8nのHTTP Requestを理解する｜REST API連携の基本

n8nには多くのサービス向けnodeがありますが、接続したいサービスに専用nodeがあるとは限りません。また、専用nodeに必要なoperationがまだ実装されていない場合もあります。

そこで使うのがHTTP Request nodeです。

n8n
→ HTTP requestを送る
→ REST APIが処理する
→ responseを受け取る
→ 次のnodeで利用する

HTTP Request nodeを理解すると、API仕様が公開されている幅広いサービスへ接続できます。大切なのは、API側が要求するrequestを正確に組み立てることです。

今日の到達点

• REST APIとHTTP Request nodeの役割を説明できる
• endpoint、method、headers、query parameters、bodyを区別できる
• GETとPOSTの最小requestを設定できる
• JSON responseを読み、必要なfieldを次のnodeへ渡せる
• status codeやエラーから確認箇所を絞り込める

HTTP Request nodeはAPIへの共通インターフェース

APIは、別のシステムが機能やデータを利用するための窓口です。REST APIでは、URLで示されるresourceに対し、HTTP methodを使って取得・作成・更新・削除などを依頼します。

入力items
→ requestを組み立てる
→ API endpointへ送信する
→ responseをitemsとして出力する

ただし、HTTP Request nodeがAPIの使い方を決めるわけではありません。利用できるmethod、URL、必要なparameter、認証、request body、response構造はAPI提供側の仕様です。n8nでは、その仕様を各設定欄へ写します。

requestを構成する要素

endpoint

https://jsonplaceholder.typicode.com/posts/1

ドメイン、path、resource IDまで含めて、APIドキュメントの指定と一致させます。似たURLでも、末尾のpathやAPI versionが違えば別のendpointです。

method

methodはresourceへ何をしたいかを表します。HTTP Request nodeではGET、POST、PUT、PATCH、DELETE、HEAD、OPTIONSを選択できます。

同じURLでもmethodが違えば別の処理になるため、API仕様から選びます。

query parameters

query parametersは、絞り込み、検索、並べ替え、ページ指定などをURLへ付加する値です。

GET /posts?userId=1

n8nではSend Query Parametersを有効にし、NameとValueを設定できます。

Name: userId
Value: 1

headers

headersはrequestに関するmetadataです。よく使う例は、送信形式を示すContent-Type、受け取りたい形式を示すAccept、認証情報を送るAuthorizationです。

Content-Type: application/json
Accept: application/json

認証が必要なAPIでは、tokenを記事やnodeの固定値へ直接書かず、Credentialsを利用します。公開テストAPIを使う今回の例ではAuthenticationをNoneにします。

body

bodyは、主にPOST、PUT、PATCHでAPIへ渡す本体データです。JSONを送る例は次のとおりです。

{
  "title": "n8n practice",
  "body": "HTTP Request test",
  "userId": 1
}

n8nではSend Bodyを有効にし、Body Content TypeをJSONに設定します。fieldごとに入力する方法と、JSON objectを入力する方法があります。

GETでJSONを取得する最小構成

秘密情報が不要なJSONPlaceholderを例にします。これは学習用のfake REST APIです。

Manual Trigger
→ HTTP Request（GET）
→ Edit Fields（必要fieldを取り出す）

HTTP Requestを次のように設定します。

Method: GET
URL: https://jsonplaceholder.typicode.com/posts
Authentication: None
Send Query Parameters: On
Query Parameter:
  Name: userId
  Value: 1

同じrequestをcurlで表すと次の形です。

curl 'https://jsonplaceholder.typicode.com/posts?userId=1'

実行すると、条件に一致するpostsのJSON arrayがresponseとして返ります。実際の値は実行時に確認します。

[
  {
    "userId": 1,
    "id": 1,
    "title": "...",
    "body": "..."
  }
]

query parameterのuserIdを別の値へ変え、返るitemsの内容が変化することを確認してください。parameter名はAPI側の仕様です。

responseを次のnodeへ渡す

HTTP Request nodeは、既定ではresponse bodyを出力します。JSON responseなら、後続nodeからfieldを参照できます。

Edit Fieldsで次のfieldを作る例です。

post_id = {{ $json.id }}

post_title = {{ $json.title }}

GETの結果が複数itemsなら、後続nodeも処理します。OUTPUTをJSON表示で確認してからExpressionを作ります。

POSTでJSONを送る

POSTでは、送信先とmethodだけでなくbodyの形式もAPI仕様へ合わせます。

Method: POST
URL: https://jsonplaceholder.typicode.com/posts
Authentication: None
Send Body: On
Body Content Type: JSON
Specify Body: Using JSON

bodyには次を設定します。

{
  "title": "n8n practice",
  "body": "HTTP Request test",
  "userId": 1
}

JSONPlaceholderは作成されたようなresponseを返しますが、書き込みは永続化されません。本番APIのPOSTは実データ作成などを発生させるため、テスト条件を確認します。

status codeとfull response

status codeは、APIがrequestをどう処理したかを示す3桁の番号です。

HTTP Request nodeは既定ではbodyだけを返し、2xx以外をエラーとして扱います。OptionsのResponseでInclude Response Headers and Statusを有効にすると、headersとstatus codeを含むfull responseを取得できます。

この場合、実データはresponseのbody内に入り、後続Expressionのpathも変わります。Never Errorを有効にするとstatus codeにかかわらずnodeを成功として扱えるため、エラーを後続で分類する場合に限って使います。

よくある失敗と確認順序

400 Bad Request

query parameter、body、JSON形式などがAPI仕様と合っているか確認します。数値と文字列、必須field、配列の表現も確認対象です。

401・403

認証情報がない、無効、または必要な権限が不足している可能性があります。credential、scope、header形式を確認します。秘密値をexecution dataや共有画面へ露出させないよう注意します。

404 Not Found

URLのtypo、resource ID、API version、廃止されたendpointを確認します。不正URLを使った学習では、実際に表示されたstatusとmessageを記録します。

429 Too Many Requests

APIのrate limitを超えた可能性があります。n8nではHTTP RequestのBatchingやnode SettingsのRetry on Failを利用できますが、待機時間や再試行回数はAPIの制限とresponse headerに合わせます。

status codeがない通信エラー

DNS、TLS、timeout、接続拒否など、APIからHTTP responseを受け取る前に失敗する場合があります。status codeがないから正常という意味ではありません。

調査は次の順番で進めます。

APIドキュメントのendpointとmethod
→ 認証
→ query／headers／body
→ 実際のrequest data
→ status codeとerror message
→ response body

実務での考え方

HTTP Request nodeは汎用的ですが、APIの契約を知らずに使える万能nodeではありません。実装前に、method、endpoint、認証方式、必須parameter、body schema、成功時response、error response、rate limitを整理します。

また、大きなresponseをすべて後続へ渡すのではなく、Edit Fieldsなどで必要fieldへ整形するとWorkflowの責務が明確になります。

今日の実習で確認すること

• 公開APIへHTTP RequestでGETする
• query parameterを1つ変更し、responseの差を見る
• OUTPUTをJSON表示してitems数とfield構造を確認する
• Edit Fieldsで必要なfieldだけを抽出する
• Include Response Headers and Statusを切り替え、出力構造を比較する
• 不正なURLを使い、実際のstatusまたはerror messageを確認する
• API仕様とn8n設定の対応関係を記録する

まとめ

HTTP Request nodeは、n8nからREST APIへrequestを送り、responseをWorkflowへ取り込む共通インターフェースです。

API仕様を読む
→ methodとendpointを決める
→ query／headers／bodyを設定する
→ responseとstatusを確認する
→ 必要なJSON fieldを次のnodeへ渡す

API側の仕様とn8n側の設定を分けて考えると、専用nodeがないサービスでも接続方法を組み立てられます。成功時だけでなく、失敗時のstatus、message、request内容まで観察することが、運用できるAPI連携への第一歩です。

参考資料

• n8n公式：HTTP Request node
• n8n公式：HTTP Request nodeのCommon Issues
• n8n公式：Handling API rate limits
• JSONPlaceholder Guide