レスポンス
レスポンスブロックはワークフローの最終ステップであり、APIコールに対して構造化されたレスポンスをフォーマットして送信します。これはワークフロー全体の「return」ステートメントのようなもので、結果をパッケージ化して返送します。
レスポンスブロックは終端ブロックです - ワークフローの実行を終了し、他のブロックに接続することはできません。
概要
レスポンスブロックでは以下のことが可能です：
APIレスポンスのフォーマット：ワークフロー結果を適切なHTTPレスポンスに構造化する
ステータスコードの設定：ワークフロー結果に基づいて適切なHTTPステータスコードを設定する
ヘッダーの制御：APIレスポンスとウェブフックにカスタムヘッダーを追加する
データの変換：ワークフロー変数をクライアントフレンドリーなレスポンス形式に変換する
動作の仕組み
レスポンスブロックはワークフローの実行を完了させます：
- データの収集 - 前のブロックからの変数と出力を収集する
- レスポンスのフォーマット - 設定に従ってデータを構造化する
- HTTP詳細の設定 - ステータスコードとヘッダーを適用する
- レスポンスの送信 - フォーマットされたレスポンスをAPI呼び出し元に返す
レスポンスブロックが必要な場合
- APIエンドポイント：ワークフローがAPI経由で呼び出される場合、レスポンスブロックは返すデータをフォーマットします
- ウェブフック：確認またはデータを呼び出しシステムに返します
- テスト：ワークフローをテストする際にフォーマットされた結果を確認できます
レスポンスを構築する2つの方法
ビルダーモード（推奨）
レスポンス構造を構築するためのビジュアルインターフェース：
- フィールドのドラッグ＆ドロップ
- ワークフロー変数の簡単な参照
- レスポンス構造のビジュアルプレビュー
エディターモード（上級者向け）
JSONを直接記述：
- レスポンス形式の完全な制御
- 複雑なネスト構造のサポート
- 動的な値には
<variable.name>構文を使用
設定オプション
レスポンスデータ
レスポンスデータは、APIの呼び出し元に送り返される主要なコンテンツです。JSONとして形式化され、以下を含めることができます：
- 静的な値
<variable.name>構文を使用したワークフロー変数への動的な参照- ネストされたオブジェクトと配列
- 任意の有効なJSON構造
ステータスコード
レスポンスのHTTPステータスコードを設定します。一般的なステータスコードには以下があります：
- 200: OK - 標準的な成功レスポンス
- 201: Created - リソースが正常に作成された
- 204: No Content - レスポンス本文のない成功
- 400: Bad Request - 無効なリクエストパラメータ
- 401: Unauthorized - 認証が必要
- 404: Not Found - リソースが存在しない
- 422: Unprocessable Entity - バリデーションエラー
- 500: Internal Server Error - サーバー側のエラー
- 502: Bad Gateway - 外部サービスのエラー
- 503: Service Unavailable - サービスが一時的に利用不可
指定されない場合、デフォルトのステータスコードは200です。
レスポンスヘッダー
レスポンスに含める追加のHTTPヘッダーを設定します。
ヘッダーはキーと値のペアとして設定されます：
| キー | 値 |
|---|---|
| Content-Type | application/json |
| Cache-Control | no-cache |
| X-API-Version | 1.0 |
使用例
APIエンドポイントのレスポンス
シナリオ：検索APIから構造化データを返す
- ワークフローが検索クエリを処理し結果を取得
- ファンクションブロックが結果をフォーマットしページネーション
- レスポンスブロックがデータ、ページネーション、メタデータを含むJSONを返す
- クライアントが200ステータスで構造化レスポンスを受信
Webhook確認
シナリオ：Webhookの受信と処理を確認
- Webhookトリガーが外部システムからデータを受信
- ワークフローが受信データを処理
- レスポンスブロックが処理状況を含む確認を返す
- 外部システムが確認を受信
エラーレスポンスの処理
シナリオ：適切なエラーレスポンスを返す
- 条件ブロックがバリデーション失敗またはシステムエラーを検出
- ルーターがエラー処理パスに誘導
- レスポンスブロックがエラー詳細とともに400/500ステータスを返す
- クライアントが構造化されたエラー情報を受信
入力と出力
レスポンスデータ：レスポンス本文のJSON構造
ステータスコード：HTTPステータスコード（デフォルト：200）
ヘッダー：キーと値のペアとしてのカスタムHTTPヘッダー
モード：レスポンス構築のためのビルダーまたはエディターモード
response.data：構造化されたレスポンス本文
response.status：送信されたHTTPステータスコード
response.headers：レスポンスに含まれるヘッダー
response.success：正常完了を示すブール値
HTTPレスポンス：API呼び出し元に送信される完全なレスポンス
ワークフロー終了：ワークフロー実行を終了
アクセス：レスポンスブロックは終端 - 後続ブロックなし
変数の参照
<variable.name> 構文を使用して、ワークフロー変数を応答に動的に挿入します：
{
"user": {
"id": "<variable.userId>",
"name": "<variable.userName>",
"email": "<variable.userEmail>"
},
"query": "<variable.searchQuery>",
"results": "<variable.searchResults>",
"totalFound": "<variable.resultCount>",
"processingTime": "<variable.executionTime>ms"
}変数名は大文字と小文字が区別され、ワークフローで利用可能な変数と完全に一致する必要があります。
ベストプラクティス
- 意味のあるステータスコードを使用する: ワークフローの結果を正確に反映する適切なHTTPステータスコードを選択してください
- 一貫した応答構造を維持する: より良い開発者体験のために、すべてのAPIエンドポイントで一貫したJSON構造を維持してください
- 関連するメタデータを含める: デバッグとモニタリングに役立つタイムスタンプとバージョン情報を追加してください
- エラーを適切に処理する: ワークフローで条件付きロジックを使用して、説明的なメッセージを含む適切なエラー応答を設定してください
- 変数参照を検証する: 応答ブロックが実行される前に、参照されるすべての変数が存在し、予想されるデータ型を含んでいることを確認してください