要約

  • 202 Accepted は、要求が処理のために受理された一方で、その処理がまだ完了していないことを示す。
  • 操作はその後も拒否、取消し、失効、権限喪失の対象となり、完了しても期待した副作用を残さないことがある。
  • 完了を前提とする判断には、元の要求を正式な状態モニターと終端結果へ結び付ける非同期操作の確認記録が必要である。

アクセス方針のローテーションを依頼する変更コントローラーを想像してみよう。サービスは操作へのリンクを添えて 202 Accepted を返す。コントローラーは変更を完了済みにし、古い認証情報を失効させ、入力材料を削除する。しかし数分後、キューから要求を取得したワーカーが方針を再確認し、操作を拒否する。要求は受理されたが、変更は一度も実行されていない。

誤りはステータスコードにない。分散操作の一段階を、その後に続く全段階の証拠へ格上げしたことにある。

RFC 9110 における 202 Accepted の定義は限定的だ。サーバーは要求を処理するために受理したが、処理は未完了である。要求は後に実行されるかもしれず、実際の処理時に許可されず実行されないこともある。最終結果について意図的に確約しない応答である。

この境界が重要なのは、HTTP の応答交換がすでに終わっているからだ。RFC 9110 は、完了した交換に対して非同期操作の後続ステータスコードを送り直す仕組みが HTTP にはないと説明する。最初の 202 を終端成功とみなすクライアントは、プロトコルが届けていない続きを作り出してしまう。

応答表現は現在の状態を説明し、状態モニターを示すか埋め込むべきだとされる。ただし URL があるだけでは完了レシートにならない。モニターは同じ操作について権威を持ち、想定したセキュリティ文脈で参照でき、判断に必要な期間保持され、終端状態を明確に表現しなければならない。一般的なキューページ、対象が変わる「最新ジョブ」エンドポイント、後に 404 となるリンクでは、不可逆な判断を支えられない。

RFC 7240 は、関連する別の信号を定義している。クライアントは Prefer: respond-async によって非同期処理を希望でき、サーバーは 202 でその希望を採用できる。この希望が選ぶのは対話方式であり、延期された処理が実行されたことではない。最終結果を確認する方法は実装ごとに定められる。

Preference-Applied の役割も狭い。RFC 7240 によれば、サーバーがどの要求プリファレンスを採用したかを示せる。したがって非同期方式が選ばれたことは確認できるが、ワーカーの開始、書込み、通知、デプロイ、その他の後続効果は確認できない。

運用記録では少なくとも三種類の事実を分離する必要がある。第一は受理で、どの要求バイト、要求者、対象、冪等キー、応答が、どの観測点で確認されたか。第二は実行で、どの操作識別子がどのキューへ入り、どのワーカーが取得し、最新の権限と依存関係がどう確認され、取消しや期限切れが介在したか。第三は結果で、どの副作用が確定し、どの終端状態が返り、その状態が現在も正式な記録として扱われているかである。

この結合は失われやすい。ゲートウェイが 202 を発行し、キューは別サービスが所有することがある。操作 URL がテナント相対で、別の認証情報では異なる意味を持つこともある。再試行は同じジョブを指す場合も、冪等性がなければ二つ目を作る場合もある。ワーカーの開始時には要求者の権限が失われているかもしれない。下流の効果が観測可能になる前に「成功」が記録されることさえある。

これらは 202 の欠陥ではない。長時間処理のあいだ接続を開き続けずに済むことが、非同期受理の価値である。必要なのは、応答を受理の証拠として保存し、それ以降の主張にはそれ以降の証拠を求める規律だ。

有用な証拠は非同期操作の確認記録である。要求メソッド、対象、本文ダイジェストを、認証済みの要求者、実行時点の権限状態、冪等キー、観測点、202 応答、操作識別子、正式な状態モニターの URI に結び付ける。その上で、キューへの登録、ワーカーの取得、最新の権限・依存関係確認、取消し状態、副作用識別子、終端結果、観測時刻、その結果を利用した判断を記録する。

出典

RFC 9110 — HTTP Semantics, 202 Accepted、RFC 7240 — Prefer Header for HTTP。