GET /v1/task/{task_id} をポーリングするか、https URL を WideRouter に渡して、
結果を受け取ることができます。後者がコールバックであり、特定のモデルに
固有のものではなく、タスク API 自体の機能です。同じフィールド、同じ
ペイロード、同じルールが、Nano Banana の画像にも Grok Imagine の
動画にも適用されます。
ポーリングではリクエストごとに API キーが必要です。コールバックでは不要です。 受信先はお客様がホストする URL です。WideRouter がそこへ呼び出すため、認証情報を読み込んだり、転送したり、誤って設定したりする必要はありません。ポーラーが
401 を返すことがある場合や、数千件のタスクを同時に実行している場合は、このページをご覧ください。送信時の 1 つのフィールド
model と input の隣に callback_url を追加します。リクエストのその他の部分に
変更はなく、送信レスポンスも通常と同じタスク ID です。
400 invalid_callback_urlとなり、不正なシークレットは、paramを
callback_secretに設定すると400 invalid_paramsとなります。
WideRouter から送信される内容
タスクごとにPOST が 1 つ送信され、タスクが
終端状態に達した時点で Content-Type: application/json されます。本文を解析する前にルーティングと
認証を行うための 3 つのヘッダーがあります。
本文は、その時点で
GET /v1/task/{task_id} が返すタスクオブジェクトとバイト単位で
完全に同一です。コールバックとポーリングの両方のパスで、同じパーサーを使用
できます。
- task.completed
- task.failed
task.failed は
課金が取り消されたことを示すシグナルでもあります。出力ファイルはタスク ID に
基づいて命名されるため、名前を変更しなくても簡単に整理できます。
配信ルール
設計時に考慮すべき重要な点は 2 つあります。
- 冪等性を確保してください。 処理に時間のかかる
200の後にリトライが行われると、同じタスクが 2 回到着する可能性があります。idをキーとしてハンドラーを識別してください。 - 応答が遅れているタスク用のポーリングフォールバックを用意してください。 送信時にタスク ID を保存します。 モデルの通常のレイテンシから数分経過してもコールバックが到着しない場合は、タスクを 1 回読み取ってください。コールバックはレイテンシを最適化するためのものであり、配信を保証するものではありません。
署名の検証
送信時にcallback_secret を送り、そのタスクに対するすべてのコールバックには
X-Wide-Signature が付与されます。これにより、リクエストが WideRouter から送信されたことと、
途中で本文が変更されていないことの2点を証明できます。これは暗号化ではありません。本文に含まれるのは
公開 URL のみです。
t はコールバックが送信された Unix 時刻です。v1 は
hex(HMAC-SHA256(callback_secret, "<t>.<raw body>")) です。つまり、タイムスタンプ、ドット、
その後にリクエスト本文を受信したままの形式で連結したものです。
1
未加工の本文を取得する
ダイジェストはバイト列に対して計算されます。JSON を解析して再度シリアライズするとバイト列が変わるため、
フレームワークが処理する前に本文を読み取ってください。
2
再計算し、定時間で比較する
同じシークレットで HMAC を再構築し、必ず定時間比較関数を使って比較してください。
==
は使用しないでください。3
古いタイムスタンプを拒否する
t が自分の時計とどちらの方向でも300秒を超えてずれているものは破棄してください。これにより、
取得されたコールバックが後からリプレイされるのを防ぎます。テストで測定されたずれは約3秒でした。callback_secret がなければ署名ヘッダーは存在せず、callback_url にある推測困難な
パスだけが、偽造された「completed」からあなたを守るものになります。
いずれの場合も、タスクをダウンロードまたは課金する前に、API キーを使って GET /v1/task/{task_id} を
再度読み取ってください。署名はコールバックの送信者を証明し、読み取り結果はタスクの現在の状態を証明します。
3つの言語でのレシーバー
各ハンドラーは同じ5つの処理を行います。生の body に対する署名を検証し、イベントヘッダーを確認し、直ちに200 で応答し、タスク
id をキューに渡し、ワーカーにタスクを再読み込みさせて出力をダウンロードさせます。
verify 関数は前のセクションのものです。出力は数メガバイトになる可能性があり、応答まで
10秒しかないため、ダウンロードは意図的にリクエストハンドラーの外で行います。
サーバーなしで試す
公開https URL を提供するリクエスト検査サービスであれば、使い捨ての受信先として利用できます。その URL を callback_url としてタスクを送信し、検査サービスにタスクオブジェクトが届く様子を確認します。自分のマシンで受信する準備ができたら、ローカルポートへの https トンネルでも同じことができます。URL はインターネットから到達可能である必要があり、LAN アドレスは送信時に拒否される点に注意してください。
速やかにダウンロードする
出力 URL は、タスクの完了から 24 時間後に機能しなくなります。コールバックは、それらの URL の存在を知ることができる最も早い時点です。受信時にダウンロードする受信側であれば、有効期限を気にする必要はありません。一方、URL だけを保存して後から読み取る受信側では、最終的に何も指さないリンクを保存することになります。次のステップ
非同期タスク API
エンベロープ、ポーリングループ、タスクの状態、エラーテーブルについて説明します。
クイックスタート
約5分で送信、ポーリング、ダウンロードを行えます。