http inノード¶
概要¶
http inノードは、外部からHTTPリクエストを受け付けるための入口を作成するノードです。
ロボシュタイン上に指定したURLの受付口を作り、外部システムやWebフォーム、Webhookなどから送信されたリクエストを起点にフローを実行できます。
例えば、外部サービスからのWebhookを受け取る、Webフォームから送信された内容を処理する、外部システムからロボシュタインのフローを呼び出す、といった用途で使用します。
http inノードで受け付けたリクエストには、通常、最後にhttp responseノードでレスポンスを返します。
原則「RS http inノード」をご利用ください
http inノードには、こちらに詳細が記載されている「http inノードの受信先が変わるバグ」があります。
ロボシュタインには、このバグを回避するために作成されたRS http inノードが用意されているため、原則「RS http inノード」の利用を推奨します。
RS http inノードは、このページで説明するhttp inノードの機能に加えて、アクセス元のIPアドレスやヘッダ値によるアクセス制限も行えます。
具体的な活用例（外部システムからWebhookを受け取る）¶
外部システムからHTTPリクエストを受け取り、その内容をもとに通知や登録処理を行う例です。
フローのイメージ図¶
① http inノードでリクエストを受け付ける¶
http inノードに、受付用のメソッドとURLを設定します。
例：
- メソッド：
POST - URL：
/webhook/alert
この場合、外部システムから指定URLへPOSTリクエストが送信されると、http inノードを起点にフローが実行されます。
② 受信した内容を後続ノードで処理する¶
http inノードで受け取ったリクエスト内容は、後続ノードで利用できます。
例えば、POSTリクエストで送信されたJSONやフォームデータは、msg.payload に格納されます。
後続のswitchノードで内容を判定したり、templateノードで通知文を作成したりできます。
③ http responseノードで応答を返す¶
http inノードで受け付けたリクエストには、最後にhttp responseノードでレスポンスを返します。
例：
msg.payload = "受付しました"
msg.statusCode = 200
このようにレスポンスを返すことで、リクエスト元の外部システムに対して処理結果を通知できます。
設定項目一覧¶
| 必須 | 項目名 | 説明 |
|---|---|---|
| ◯ | メソッド | 受け付けるHTTPメソッドを指定します。GET、POST、PUT、DELETE、PATCHを選択できます。 |
| ファイルのアップロード | POSTリクエストでファイルアップロードを受け付ける場合にチェックします。メソッドが「POST」の場合のみ表示されます。 | |
| ◯ | URL | リクエストを受け付けるURLのパスを指定します。 |
| 名前 | フローエディター上で表示されるノード名を任意で指定できます。 |
メソッドについて¶
メソッドでは、どの種類のHTTPリクエストを受け付けるかを指定します。
| メソッド | 主な用途 |
|---|---|
| GET | URLのクエリパラメータを受け取る場合に使用します。 |
| POST | 外部システムからデータを送信してもらう場合に使用します。 |
| PUT | データの更新リクエストを受け取る場合に使用します。 |
| DELETE | データの削除リクエストを受け取る場合に使用します。 |
| PATCH | データの一部更新リクエストを受け取る場合に使用します。 |
WebhookやWebフォームの受付では、POSTを使用することが多いです。
URLについて¶
URLには、外部からアクセスされる受付用のパスを指定します。
例：/webhook/alert
ここで指定するのはパスのみです。外部から実際にアクセスするURLは、インスタンスのAPIのURLの後ろに、このパスをつなげたものになります。
（インスタンスのAPIのURL）/webhook/alert
インスタンスのAPIのURLは、管理画面の「インスタンス一覧」画面で対象インスタンスの「編集」ボタンを押すと確認できます。確認方法の詳細はこちらをご確認ください。
インスタンスのAPIのURLは末尾が /api になっているため、http inノードのURLに /api を含める必要はありません。
URLは、用途が分かる名前にしておくと管理しやすくなります。
例：
/form/contact/ticket/create/webhook/monitoring-alert
受信データについて¶
http inノードで受け取ったデータは、リクエストの種類によって msg.payload に格納される内容が変わります。
| リクエスト | 主な格納先 | 内容 |
|---|---|---|
| GET | msg.payload |
クエリパラメータが格納されます。 |
| POST | msg.payload |
リクエスト本文が格納されます。 |
| PUT | msg.payload |
リクエスト本文が格納されます。 |
| PATCH | msg.payload |
リクエスト本文が格納されます。 |
| DELETE | msg.payload |
リクエスト本文がある場合は格納されます。 |
リクエスト本文は、送信元の形式（Content-Type）に応じて以下のように格納されます。
| 送信形式 | msg.payload の形 |
|---|---|
JSON（application/json） |
オブジェクトとして格納されます。 |
フォーム（application/x-www-form-urlencoded） |
オブジェクトとして格納されます。 |
テキスト（text/plain） |
文字列として格納されます。 |
また、リクエスト情報やレスポンス返却に必要な情報として、以下も後続ノードへ渡されます。
| プロパティ | 内容 |
|---|---|
msg.req |
受信したHTTPリクエストに関する情報です。クエリパラメータは msg.req.query、リクエスト本文は msg.req.body、リクエストヘッダは msg.req.headers で参照できます。 |
msg.res |
http responseノードでレスポンスを返すために必要な情報です。 |
msg.payload |
GETの場合はクエリパラメータ、POSTなどの場合はリクエスト本文が格納されます。 |
POSTなどでURLにクエリパラメータを付けた場合、msg.payload にはリクエスト本文が入るため、クエリパラメータは msg.req.query から参照してください。
なお、クエリパラメータの値はすべて文字列として格納されます。
http responseノードとの関係¶
http inノードで受け付けたリクエストには、通常、最後にhttp responseノードでレスポンスを返します。
http responseノードを接続しない場合、リクエスト元に応答を返せず、リクエスト元が応答待ちのままタイムアウトになる場合があります。 そのため、http inノードを使用するフローでは、基本的にhttp responseノードまで含めて構成してください。
http responseノードで返せる主な値¶
http responseノードでは、以下の値をもとにレスポンスを返します。
| プロパティ | 内容 |
|---|---|
msg.payload |
レスポンス本文として返す内容です。オブジェクトを設定した場合はJSON形式で返されます。 |
msg.statusCode |
HTTPステータスコードを指定します。未指定の場合は 200 として返されます。 |
msg.headers |
レスポンスヘッダーを指定する場合に使用します。 |
msg.cookies |
Cookieを返す場合に使用します。 |
例えば、正常に受付したことを返す場合は、前段のfunctionノードで以下のように設定します。
msg.statusCode = 200;
msg.payload = {
result: "success",
message: "受付しました"
};
return msg;
この状態でhttp responseノードへ渡すと、リクエスト元に処理結果を返せます。
利用例¶
例1：外部システムからWebhookを受け取る¶
外部システムから障害通知を受け取り、内容に応じて通知処理を行う例です。
設定例：
- メソッド：
POST - URL：
/webhook/monitoring-alert
外部システムからPOSTリクエストが送信されると、フローが実行されます。
例2：問い合わせフォームの送信内容を受け取る¶
Webフォームから送信された内容を受け取り、担当者へメール通知する例です。
設定例：
- メソッド：
POST - URL：
/form/contact
送信されたフォーム内容を msg.payload として受け取り、templateノードでメール本文を作成できます。
例3：GETパラメータを受け取る¶
URLのクエリパラメータを受け取る例です。
設定例：
- メソッド：
GET - URL：
/status
外部から以下のようにアクセスされた場合、
（インスタンスのAPIのURL）/status?host=server01
msg.payload にクエリパラメータが格納されます。
{
"host": "server01"
}
この値をもとに、後続のswitchノードやfunctionノードで処理を分岐できます。
例4：処理結果をJSONで返す¶
外部システムへJSON形式で処理結果を返す例です。functionノードで以下のように設定します。
msg.statusCode = 200;
msg.payload = {
result: "success",
message: "処理が完了しました"
};
return msg;
この状態でhttp responseノードへ渡すと、JSON形式のレスポンスを返せます。
注意点¶
URLの重複に注意する¶
同じメソッド・同じURLのhttp inノードを複数作成すると、どのフローで受け付けるか分かりにくくなるうえ、「http inノードの受信先が変わるバグ」の原因にもなります。 URLは用途ごとに分かりやすく設定し、重複しないように管理してください。RS http inノードでは、設定済みのURLは入力できないため、重複を防げます。
http responseノードを忘れない¶
http inノードで受け付けたリクエストには、基本的にhttp responseノードで応答を返します。 http responseノードがない場合、リクエスト元が応答待ちの状態になったり、タイムアウトになる可能性があります。
外部公開範囲に注意する¶
http inノードで作成したURLは、外部システムから呼び出される入口になります。 そのため、どの範囲からアクセスできるURLなのか、認証やIP制限が必要か、事前に確認してください。 インスタンス全体の接続元IPアドレスは、「インスタンス一覧」画面の「編集」から制限できます。ノード単位でアクセスを制限したい場合は、RS http inノードのアクセス認可を利用してください。 特に、社外からアクセスされる用途で利用する場合は、セキュリティ要件を確認したうえで設計してください。
受信データの形式に注意する¶
POSTやPUTで受け取るデータは、送信元のContent-Typeや送信形式によって、msg.payload の形が変わります。
JSON、フォームデータ、テキスト、ファイルアップロードなど、どの形式で送信されるかを事前に確認してください。
ファイルアップロードの扱いに注意する¶
POSTリクエストでファイルアップロードを受け付ける場合は、「ファイルのアップロード」にチェックを入れます。 アップロードされたファイルはメモリ上で扱われるため、サイズの大きいファイルを受け付ける場合は、運用上の制限や処理方法を確認してください。
レスポンスのステータスコードを適切に設定する¶
正常終了時は 200、作成完了時は 201、入力エラー時は 400、認証エラー時は 401、権限不足時は 403、サーバー側の処理エラー時は 500 など、処理結果に応じたステータスコードを返すと、呼び出し元が結果を判断しやすくなります。
機密情報の取り扱いに注意する¶
外部から受け取るリクエストには、認証情報、トークン、個人情報などが含まれる場合があります。 debugノードで表示したり、画面キャプチャやマニュアルに掲載したりする場合は、必要に応じてマスキングしてください。
関連ノード¶
- RS http inノード：アクセス制限が可能なロボシュタイン専用のhttp inノードです。原則こちらの利用を推奨します。
- http responseノード：http inノードで受け付けたリクエストにレスポンスを返す場合に使用します。
- switchノード：受信した内容をもとに処理を分岐する場合に使用します。
- changeノード：レスポンス本文やステータスコードを設定する場合に使用します。
- templateノード：受信内容をもとに通知文やレスポンス本文を作成する場合に使用します。
- functionノード：受信データの複雑な加工やバリデーションを行う場合に使用します。
- debugノード：受信したリクエスト内容を確認する場合に使用します。
- catchノード：処理中に発生したエラーを検知する場合に使用します。
まとめ¶
http inノードは、外部からHTTPリクエストを受け付け、ロボシュタインのフローを実行するためのノードです。
Webhookの受付、Webフォームの送信内容の処理、外部システムからのフロー呼び出しなどで活用できます。
http inノードを使用する場合は、基本的にhttp responseノードと組み合わせ、リクエスト元へ適切なレスポンスを返す構成にしてください。
また、外部から呼び出される入口になるため、URLの管理、アクセス制御、受信データの形式、機密情報の取り扱いには注意が必要です。