HTTP 要求

HTTP 要求ノードは、設定、認証、応答の分岐とともに Web アドレスに要求を送信します。

機能

HTTP 要求を URL に送信し、その後のノードで応答を利用できるようにします。

認証オプション

1 つの HTTP 要求ノードで両方の認証方法をカバーします。これらの方法は [ 認証 ] フィールドで選択します。

• 手動認証: メソッド、URL、ヘッダー、本文、資格情報をインラインで設定します。これは、資格情報がノードで管理される外部の Representational State Transfer (REST) エンドポイント (API キー ヘッダーやベアラー トークンなど) に適合します。
• コネクタ ベースの認証: 要求は接続を経由するため、接続で認証を処理し、資格情報はノードで設定されていません。Integration Service を介して接続されるサービスに対して、資格情報を一元管理するよう適合します。

構成のリファレンス

フィールド	Required	既定 (Default)	説明
インポートまたはエクスポート	いいえ	なし	フィールドの上にあるメニュー。[cURL からインポート ] は cURL コマンドを解析し、メソッド、URL、ヘッダー、本文を自動的に入力します。
認証	はい	手動認証	要求の認証方法手動認証では 、資格情報を要求ヘッダーで渡します。コネクタ ベースの認証 では、以下に示すように、接続を介して要求を送信します。
メソッド	はい	GET	要求の HTTP メソッド。サポートされている値は、 GET、 POST、 PUT、 PATCH、 DELETEです。
URL	はい	なし	要求の送信先の完全な URL ( https:// スキームを含む)。[ 固定値] フィールドには、値が二重中括弧で挿入されます (例: https://api.example.com/users/{{ $vars.userId }})。
ヘッダー	いいえ	なし	HTTP 要求ヘッダーとして送信されるキーと値のペア。ヘッダー名と値では、変数式がサポートされています。
クエリ パラメーター	いいえ	なし	キーと値のペアをクエリ文字列として URL に追加します。名前と値では、変数式がサポートされています。
コンテンツの種類	いいえ	application/json	要求本文の Multipurpose Internet Mail Extensions (MIME) の種類です。サポートされている値は、 application/json、 application/xml、 text/plain、 application/x-www-form-urlencodedです。
本文	いいえ	空	POST、PUT、PATCH の要求の要求本文です。コード エディターで値を直接入力するか、変数の式を使用します。
[分岐] タブ	いいえ	既定の出力のみ	応答のプロパティに基づいてワークフローをルーティングする応答分岐各ブランチには、名前と条件の式があります。
タイムアウト (詳細設定 タブ)	いいえ	PT15M	応答を待機する最大時間です (国際標準化機構 (ISO) 8601 形式。
リトライ回数 ([詳細設定 ] タブ)	いいえ	0	要求が失敗した場合に要求をリトライする回数です。リトライは、タイムアウト値をバックオフ間隔として使用します。

コネクタ ベースの認証

認証がコネクタ ベースの認証の場合、パネルには手動のフィールドではなく以下のフィールドが表示されます。

フィールド	Required	説明
コネクタ	はい	要求を送信するコネクタ (例: Slack)。
コネクション (コネクタの名前にちなんだ名前、 例: Slack コネクション)	はい	使用するコネクションです。
メソッド	はい	要求の HTTP メソッド。
ベース URL	いいえ	コネクタのベース URL です。プレースホルダーとして表示されます https://slack.com/api。
パス	いいえ	REST API 要求のエンドポイント パス。
ヘッダー	いいえ	キーと値のペア (最大 20)。コネクタは、独自の Authorization、 Accept、および Content-Type ヘッダーを自動的に追加します。
クエリ パラメーター	いいえ	キーと値のペア (最大 20)。

エディターは、 Authorization、 Content-Type、 Accept、 X-Api-Keyなどの一般的なヘッダー名を提案します。クエリ パラメーターの場合、名前 page と 値 2 のパラメーターを追加すると、要求が https://api.example.com/items?page=2に送信されます。

ノードは分岐の条件を順番に評価し、最初の一致に従います。一致する分岐がない場合、ワークフローは 既定 の出力に従います。

分岐条件式は、判断ノードおよびスイッチ ノードと同じ JavaScript 構文を使用します。

$vars.httpRequest1.output.code === 200

$vars.httpRequest1.output.code >= 400

各分岐は、キャンバス上のノードの右側に既定 のハンドルとともに 、個別の出力ハンドルとして表示されます。

一般的なタイムアウト値は次のとおりです。

• PT30S: 30 秒
• PT5M: 5 分
• PT15M: 15分
• PT1H: 1 時間

資格情報

要求を認証するには、次の 2 つの方法があります。

手動認証

資格情報を要求ヘッダーで直接渡します。API キー認証の場合は、名前 X-Api-Key 、値をキーに設定したヘッダーを追加します。ベアラー トークン認証の場合は、Bearer <your-token>のような値の Authorization ヘッダーを追加します。

トークンや API キーなどの機密性の高い値をハードコーディングするのではなく、シークレット変数に格納します。

コネクタ ベースの認証

[プロパティ] パネルでコネクションを選択します。このコネクションでは資格情報が要求に自動的に挿入されるため、ヘッダーを自分で管理する必要はありません。

コネクションは、資格情報の一元管理、トークンの自動更新、および複数のワークフローで同じ API 資格情報を共有するケースに適しています。

注:

Create a connection describes how to create one.

例

例 1: 基本的な GET 要求

パブリック API から 1 つのリソースを取得します。

ノードは、 メソッドを GET に、 URL を https://jsonplaceholder.typicode.com/posts/1に設定して構成します。その他のすべてのフィールドは既定値のままです。

応答は下流のスクリプト ノードで利用できます。

const body = $vars.httpRequest1.output.body;
const status = $vars.httpRequest1.output.code;

return {
  title: body.title,
  userId: body.userId,
  status: status
};

応答オブジェクトは $vars.httpRequest1.output で利用可能で、次の 3 つのフィールドが含まれます。

• $vars.httpRequest1.output.body: 解析された応答本文です。
• $vars.httpRequest1.output.code: HTTP ステータス コード (例: 200) です。
• $vars.httpRequest1.output.headers: 応答ヘッダーを含む オブジェクトです。

例 2: JSON 本文を使用した POST 要求

JSON ペイロードを送信して新しいリソースを作成します。

ノードは、[メソッド] を [POST] に設定し、[URL を https://api.example.com/orders] に設定し、[Authorization ヘッダー] の値を Bearer {{ $vars.apiToken }}に設定し、[コンテンツの種類] を [application/json] のままにして構成します。本体:

{
  "product": "Widget",
  "quantity": 5,
  "customer_id": "cust_12345"
}

作成されたリソースの ID は、下流のノードで確認できます。

const orderId = $vars.httpRequest1.output.body.id;
return { orderId: orderId };

要求が失敗し、エラー ハンドルを接続した場合、エラーの詳細は $vars.httpRequest1.errorで確認できます。

// In a Script node connected to the error handle
const errorMessage = $vars.httpRequest1.error.message;
const errorStatus = $vars.httpRequest1.error.status;

return {
  failed: true,
  reason: errorMessage,
  httpStatus: errorStatus
};

エラー オブジェクトには以下が含まれます。

• code
• message
• detail
• category
• status

例 3: 分岐を使用して応答をルーティングする

応答分岐を使用すると、別個の判断ノードを設定せずに、ワークフローは API の応答に基づいてさまざまなパスをたどることができます。

ノードは、[メソッド] を [GET] に設定し、[URL を https://api.example.com/users/{{ $vars.userId }}] に設定し、[分岐] タブに 2 つの分岐 (条件 $vars.httpRequest1.output.code === 200 の Success と条件 $vars.httpRequest1.output.code === 404の Not Found ) で構成されます。

これで、ノードのキャンバス上に次の 3 つの出力ハンドルが追加されました。

• 成功: ユーザー データを処理するノードに接続します。
• 見つかりません: 見つからないユーザーを処理するノードに接続します。
• 既定: 他のステータス コードのフォールバック パスに接続します。

下流の各パスは完全な応答を受け取ります。たとえば、Success 分岐では次のようになります。

const user = $vars.httpRequest1.output.body;
return { name: user.name, email: user.email };

HTTP 要求と統合ノードの選択

HTTP 要求ノードは、API を呼び出すための汎用ツールとして使用します。呼び出しているサービスに専用の統合ノードが存在する場合は、専用の統合ノードを使用します。

HTTP 要求は次の場合に使用します。	統合ノードは、次の場合に使用します。
API の [ ノードを追加 ] パネルには専用のコネクタがありません	A connector exists for the service, such as Slack, Salesforce, or HubSpot CRM
ヘッダー、クエリ パラメーター、本文の形式を完全に制御する必要がある	手動で設定しない、事前に型指定された入力と出力が必要な場合
新しい API または内部サービスに対してプロトタイピングを行う場合	サインインとトークンの更新を処理してくれるコネクションが必要な場合
この API では、非標準の認証スキームが使用されます	API によってコントラクトが変更されても動作しなくなる、保守可能なワークフローが必要である

原則として、[ ノードを追加 ] パネルで最初にコネクタを検索するのが良い順序で、ターゲット サービスにコネクタが存在しない場合のフォールバックとして [HTTP 要求] を使用します。

次のステップ

• スクリプト ノード: HTTP 応答データを変換および処理します。
• 意思決定ノード: 応答分岐の代替として、条件で分岐します。
• 変数とデータ フロー: $vars、式の構文、変数のスコープ設定。
• コミュニティ: UiPath フォーラムで質問したり、他のビルダーとワークフローを共有したりできます。