ジョブ作成 API
リクエストボディ
バッチのリクエストボディは snake_case(
process_type)を使用します — インライン Guard API の processType(camelCase)とは表記が異なります。202 Accepted
job_id を保管し、照会に使用します。
検証のタイミング — 受付時点では、認証・Kill Switch・process_type・許可範囲のみを同期的に検証します(失敗するとジョブは作成されず、即時に拒否されます)。原本の存在・サイズ・形式は処理時点で検査され、問題があればジョブが FAILED として確定します。バッチのエラーを参照してください。
リトライと重複 — 冪等トークンはありません。同一のリクエストを再送信すると、それぞれ別のジョブが作成されます。レスポンスの喪失時には重複受付が起こり得ますが、同じ入力・ポリシーの成果物が同じ名前でアトミックに上書きされるため、tgt の最終状態は同一です。受付済みジョブの job_id を失った場合は、後述の原本アドレス検索で復旧してください。
ジョブ照会 API
200
- 照会は、そのジョブを作成したプロジェクトの API Key でのみ可能です。
- Kill Switch の発動中は、ジョブの作成と照会がどちらも拒否されます。
- ジョブ照会の保持期間は運用ポリシーに従い、過去のジョブの履歴は Opticon で確認します — 各ジョブのトレースに受付情報(
src_s3_url・tgt_s3_url・process_type・job_id)と判定・エラーが併せて記録されます。
原本アドレスによるジョブ検索
job_id を失った場合は、原本アドレスから直近のジョブを検索して復旧します:
results は含まれません — 詳細は job_id の単体照会で確認してください)。
ポーリングパターン
1
ジョブの作成
POST /v1/guard/s3 を呼び出し、レスポンスの job_id を保管します。2
定期照会
GET /v1/guard/s3/jobs/{job_id} を定期的に呼び出します。status が PENDING / PROCESSING の間は待機を続けます。3
確定状態での分岐
COMPLETED なら action で分岐し(PASS / MASK は tgt_s3_url から成果物を回収、BLOCK は成果物なし — 理由は results)、FAILED なら error.code で分岐します。