> ## Documentation Index > Fetch the complete documentation index at: https://help.dingtalk.io/llms.txt > Use this file to discover all available pages before exploring further. # 自動化 HTTP リクエストの送信 > HTTP リクエストの送信は AI テーブル自動化フローの中核操作で、事前設定されたネットワークリクエストを指定 URL に送信し、外部システムの API 呼び出しやデータ連携をトリガーできます。本機能は AI テーブルとシームレスに連携でき... # 1 機能概要 HTTP リクエストの送信は AI テーブル自動化フローの中核操作です。事前設定されたネットワークリクエストを指定 URL に送信することで、外部システムの API 呼び出しやデータ連携をトリガーできます。本機能は AI テーブルのフィールドデータや自動化フローの中間結果とシームレスに連携でき、サードパーティプラットフォームとの深い統合を実現します。生成されたレスポンス結果は、後続の自動化ステップの入力として使用でき、完全な自動化ワークフローを構築できます。 HTTP リクエストを発行することで、指定 URL にネットワークリクエストを送信し、サードパーティシステムとの連携を実現できます。例： * 内部システムへのデータ同期：データを ERP・CRM などの内部システムに同期し、手動同期を不要にします。 * データの取得とクローリング：Web クローラーを構築し、Web ページの内容を取得して必要なデータを抽出します。 * サードパーティサービスの統合：決済・SMS 送信・位置情報取得など、各種サードパーティサービスを統合します。 # 2 説明 ## 2.1 リクエストメソッド リクエストの種類を選択します（必須）。リクエストの種類により、サーバーに対してどのような操作を実行するかが決まります。 | | | | --------- | ------------------------------------------------------------------------------------------------------------------------------ | | リクエストメソッド | 説明 | | GET | **サーバーデータの取得** 指定したページまたはデータ API にリクエストを送り、レスポンスボディを返します。情報の取得・参照によく使用されます。 | | POST | **サーバーへのデータ送信（フォーム送信やファイルアップロードなど）** 指定リソースへのデータ送信（フォーム送信、ファイルアップロードなど）に使用し、送信データはリクエスト本文に含まれます。新規リソースの作成や既存リソースの変更によく使用されます。 | | PUT | **サーバーデータの変更** リソース全体の置き換えに使用し、完全なデータの提供が必要です。通常は更新操作に使用します。 | | PATCH | サーバーデータの一部変更 | | OPTIONS | サーバーがサポートするリクエスト種類の取得 | | DELETE | サーバーデータの削除 | ## 2.2 パラメータの説明 ### 2.2.1 GET リクエスト | パラメータタイプ | パラメータ名 | 説明 | | -------- | --------- | ----------------------------------------------------------------- | | 入力パラメータ | リクエスト URL | パスとクエリパラメータを含む（例：` | | 入力パラメータ | クエリパラメータ | URL に付加されるキーと値のペア（例：`?page=1&limit=10`）。 | | 入力パラメータ | リクエストヘッダー | 任意。認証情報の伝達に使用（例：`Authorization: Bearer token`）。 | | 出力パラメータ | レスポンスボディ | 返されるデータ内容（JSON、XML、テキストなど）。 | ### 2.2.2 POST/PUT/PATCH/DELETE リクエスト | パラメータタイプ | パラメータ名 | 説明 | | -------- | --------------------------- | -------------------------------------------------------------------------------- | | 入力パラメータ | リクエスト URL | パスとクエリパラメータを含む（例：` | | 入力パラメータ | クエリパラメータ | 任意。URL に付加されるキーと値のペア（例：`?action=update`）。 | | 入力パラメータ | リクエストヘッダー | コンテンツタイプの指定（例：`Content-Type: application/json`）と認証情報の伝達に使用。 | | 入力パラメータ | リクエストボディ | リクエストヘッダーの Content-Type で設定したタイプと一致させる必要があります。 | | 出力パラメータ | レスポンスボディ | 返されるデータ内容（JSON、XML、テキストなど）。 | | 出力パラメータ | 戻り値（レスポンスボディが JSON の場合のみ設定） | レスポンスボディが JSON の場合、フィールドを抽出して後続フローで利用できます（例：`{"id": 123, "status": "success"}`）。 | 📌 API シークレットに関する説明 リクエスト先のシステムが署名検証を必要とする場合、apiSecret を入力していると、システムが受信した HTTP リクエストヘッダーに署名関連のヘッダーが含まれます。 * x-ddpaas-signature-timestamp：\<署名時のタイムスタンプ> * x-ddpaas-signature：\<署名文字列> ここで \<署名文字列> = calcSignature(apiSecret, \<署名時のタイムスタンプ>) です。apiSecret は登録時に指定した署名キーです。 リクエスト先のシステムは、以下の方法で署名を計算し、署名文字列が正しいかを検証することで、不正な呼び出しを防止できます。 ```java theme={"theme":{"light":"github-light","dark":"github-dark"}} public static String calcSignature(String apiSecret, long ts) { try { Mac mac = Mac.getInstance("HmacSHA256"); SecretKeySpec key = new SecretKeySpec(apiSecret.getBytes(), "HmacSHA256"); mac.init(key); return Base64.getEncoder() .encodeToString(mac.doFinal(Long.toString(ts).getBytes())); } catch (NoSuchAlgorithmException | InvalidKeyException e) { log.error("sign api secret failed", e); } } ``` ### 2.2.3 出力パラメータの定義とレスポンスボディの選択 * HTTP リクエストの戻り値（出力パラメータ）は、後続のステップに渡されます。レスポンスボディの種類により、後続ステップでこれらのパラメータをどのように解析・参照するかが決まります。 * レスポンスボディに JSON を選択すると、後続ステップでは JSON のルールに従って戻り値を構造化解析します。そのため、戻り値のサンプルを手動で入力し、後続ステップでこれらの構造化データを参照できるようにする必要があります。 * レスポンスボディに Text を選択すると、後続ステップでテキスト形式として戻り値全体を参照できます。 * レスポンスボディに None を選択すると、後続ステップで戻り値のパラメータを参照できません。 # 3 よくある質問 ## 3.1 よくある質問 * 質問：デフォルトの HTTP 失敗ルールは以下のケースを含みます。 * ステータスコード ≠ 200 * リクエストタイムアウトなどのシステム例外による失敗。 * 質問：HTTP リクエストのタイムアウトエラーはどのような原因で発生しますか？ 回答：原因：ネットワーク遅延、サーバーレスポンスの遅延、ファイアウォール／プロキシの制限、DNS 解決の異常、サーバー負荷の高さなど。 * 質問：AI テーブル自動化フローから送信する HTTP リクエストは、固定 IP アドレス（IP ホワイトリスト）の設定によるセキュリティ強化に対応していますか？ 回答：対応しています。多くのプラットフォームでは、送信元 IP のホワイトリスト設定や固定 IP の紐付けが可能で、プラットフォーム管理画面または API ゲートウェイで設定が必要です。203.119.128.0/17、59.82.0.0/16、140.205.0.0/16、106.11.0.0/16 * 質問：リクエスト URL に直接クエリパラメータを付加して追加データを渡せますか？ 回答：対応しています。`?key1=value1&key2=value2` の形式でパラメータを付加できます。GET リクエストに適しており、一部の POST リクエストでも使用可能です（サーバー側の対応が必要）。 * 質問：HTTP リクエストが正しく解析されない一般的な原因は？リクエストの有効性をどう検証しますか？ 回答：原因： * リクエスト形式エラー（JSON 構文エラーなど）。 * エンコーディングの問題（`Content-Type` が正しく設定されていないなど）。 * サーバー側 API の変更やバージョン不一致。 * 必要なリクエストヘッダーの欠落（認証トークンなど）。 検証方法： * ツール（Postman、curl など）で同じリクエストを手動送信。 * レスポンスステータスコードを確認（400 はクライアントエラー、5xx はサーバーエラー）。 * デバッグログの有効化やパケットキャプチャ解析（Wireshark など）。 * 質問：JSON 形式に準拠した HTTP レスポンスボディには、どのような必須構造や制約がありますか？ 回答： * 構造の制約： * 有効な JSON オブジェクト（`{}`）または配列（`[]`）である必要があります。 * フィールド名はダブルクォーテーションで囲む必要があります（`"key"`）。 * サポートされるデータ型：文字列、数値、ブール値、オブジェクト、配列、`null`。 * 一般的な慣例：ステータスコード（`"code"`）、メッセージ（`"message"`）、データ（`"data"`）などのフィールドを含めます。 * 質問：HTTP リクエストで設定可能な Key-Value パラメータペアの最大数はどれくらいですか？ 回答： * 厳密な制限はありませんが、以下の要因の影響を受けます。 * URL の長さ制限（通常 2048 文字以内を推奨）。 * サーバー側の解析能力（一部のサービスではパラメータ数を制限）。 * パフォーマンスの最適化（過度に冗長なパラメータを避ける）。 * 質問：後続の自動化ステップで、HTTP レスポンスから返された配列型データを参照して処理できますか？ 回答：ループによる繰り返し処理、またはメッセージ送信時のフィールド組み合わせ出力で処理できます。 * 質問：グループのカスタムロボットでメッセージを送信する際、オープンプラットフォームのサンプルコードをそのままコピーしても成功しない場合、どのような設定やコード適応の問題が考えられますか？ 回答： * よくある問題： 1. Webhook アドレスのエラー：実際に生成された URL や Token に置き換えていない。 2. 権限不足：ロボットが対象グループに参加していない、または操作権限がない。 3. 形式の不一致：リクエストボディの形式が API 要件と異なる（`Content-Type` が正しく設定されていないなど）。 4. 署名検証の失敗：署名の欠落またはエラー（タイムスタンプやキーが計算されていないなど）。 5. ネットワーク制限：ファイアウォールやプロキシによるリクエストブロック。 * 解決方法： * サンプルコードのプレースホルダー（`{token}` など）を慎重に確認する。 * デバッグツールでリクエストヘッダー・リクエストボディ・レスポンス内容を確認する。 * オープンプラットフォームの開発者ドキュメントを参照するか、テクニカルサポートに連絡する。