プロンプトと対象範囲
面接官は次のように質問する可能性があります：「HTTP 1xx 暫定レスポンスと 102 Processing は何を意味しますか？時間のかかるリクエストで進捗フィードバックが必要な場合、どのように設計しますか？」
評価されるポイントは、リクエストが完了していないことを示すプロトコルシグナル、最終レスポンス、そして非同期オペレーションリソースを明確に区別できるかどうかです。RFC 9110 では、最終的な非 1xx レスポンスの前に 0 個以上の 1xx 暫定レスポンスを返すことが許可されていますが、102 を汎用的なパーセンテージ進捗プロトコルに変えるわけではありません。102 は RFC 2518 で WebDAV ステータスとして登場し、RFC 4918 によって WebDAV から削除されました。これを提案する前に、まずプロトコルのバージョン、クライアント、および仲介者を検証してください。
面接官が見ているポイント
- 1xx レスポンスが暫定的なものであり、リクエストを完了させないことを理解しているか。
- 100 Continue、101 Switching Protocols、および 102 Processing を区別できるか。
- 普遍的なサポートを約束するのではなく、102 の WebDAV における経緯を認識しているか。
- 長時間実行されるプロダクトフローに対して、202 とステータスリソースの組み合わせ、SSE、または WebSocket を適切に選択できるか。
- プロキシ、タイムアウト、リトライ、キャンセル、冪等性、および結果取得を考慮に入れているか。
明確化のための質問
- リクエストは同期のままである必要がありますか、それともバックグラウンド処理に移行できますか？
- リバースプロキシとゲートウェイは 1xx レスポンスを転送してクライアントに公開しますか？
- プロダクトに必要なのは keep-alive のヒントですか、それとも観測可能なステージやパーセンテージですか？
- その操作には、リトライによって重複実行される可能性のある副作用がありますか？
- 有効期限やアクセス制御を備えた独立した結果リソースはありますか？
30秒の回答例
次のように回答できます：
1xx レスポンスは暫定的なものであり、クライアントは引き続き最終的な非 1xx レスポンスを必要とします。102 Processing は WebDAV の長時間処理シナリオに由来するため、一般的な進捗モデルではなく、すべての仲介者を通過できるとは限りません。処理を非同期にできる場合、私は 202 を返し、安定した状態、エラー、キャンセル、結果リンクを公開する認可されたステータスリソースを提供します。接続を開いたままにする必要がある場合は、クライアントのサポート状況に応じて SSE やその他の明示的なイベントプロトコルを検討し、実際のプロキシ経路をテストします。
段階的な思考プロセス
レスポンスライフサイクルを定義する
暫定ステージと最終ステージを分離します：
HTTP/1.1 102 Processing
HTTP/1.1 200 OK
Content-Type: application/json
{"result":"done"}102 はリクエストを終了させず、完了を保証するものでもありません。RFC 9110 の重要な制約は、最終的な非 1xx レスポンスが後から必ず続くということです。暫定レスポンスが失われたとしても、それ自体がビジネスロジック上の失敗を証明するわけではありません。
102 の境界線を設定する
RFC 2518 では、102 は長時間処理中にクライアントがアクティブな接続を切断されたと誤認するのを防ぐための WebDAV ヒントとして説明されていました。これは、標準化された percentComplete、ステージ値、エラーセマンティクスを持つワークフローリソースではありません。RFC 4918 でその WebDAV の定義が削除されたため、新しい API ではステータスコードの数値だけに依存せず、ターゲットとなる実装と互換性をドキュメント化する必要があります。
プロダクトのニーズに応じたプロトコルを選択する
ポーリングが許容される場合は、アクションとその状態を分離します。リクエスト受付時に 202 と Location を返し、Pending、Running、Succeeded、Failed、Canceled などの安定した状態を公開します。リアルタイム UI でステージの更新が必要な場合は SSE を追加し、双方向制御の妥当性がある場合にのみ WebSocket を検討します。どの選択肢でも、再接続、バックオフ、キャンセル、認可に関する設計が必要です。
重複送信と最終的な完了を処理する
作成リクエストに対して冪等性キー（idempotency key）を受け入れ、リクエストのフィンガープリントを操作 ID とともに永続化します。同じキーによるリトライでは、別の副作用をキューに追加する代わりに同一の操作を返します。ステータスの読み取りを反復可能にし、結果 URL をテナントチェックと有効期限で保護し、リトライ境界を持つ構造化エラーを公開します。切断、タイムアウト、または 102 レスポンスは、ビジネス上の結論ではありません。
模範解答
私はまず、keep-alive のヒントと観測可能な進捗を区別します。同期リクエストがゲートウェイのタイムアウトを超える可能性がある場合、102 を汎用的な進捗 API としては使用しません。1xx は暫定的なものであり、102 には WebDAV の経緯があり、仲介者によるサポートも均一ではないためです。私の標準的なアプローチは、送信内容を検証し、操作 ID とステータス URL とともに 202 を返し、明確なステージ情報、更新日時、構造化エラー、キャンセル手段、および結果 URL を公開することです。送信には冪等性キーを含め、リトライによって重複処理が発生しないようにします。リアルタイム UI に対しては SSE を追加し、last event ID またはステータスリソースを通じた復旧を可能にします。セキュリティやコンプライアンスのリスクは、正式なエスカレーションと監査パスを使用します。これにより、プロトコルシグナル、操作状態、および結果リソースを明確に分離できます。
よくある間違い
- フィールドやクライアントの規約がないまま、102 をパーセンテージ進捗レスポンスと呼ぶこと。
- いかなる 1xx も成功とみなしたり、接続を閉じてよい許可とみなしたりすること。
- RFC 4918 による WebDAV からの 102 の削除を無視し、普遍的な WebDAV サポートを主張すること。
- CDN、プロキシ、ゲートウェイ、ブラウザのテストを省略し、オリジンサーバーのみについて議論すること。
- ステータスリソース、冪等性戦略、失敗状態、または結果の認可なしに 202 を返すこと。
- 切断、タイムアウト、またはリトライを失敗の証明として扱い、副作用を重複して発生させること。
フォローアップ質問と回答
1. 102 と 202 の決定的な違いは何ですか？
102 は同一リクエストに対する暫定レスポンスであり、最終レスポンスはまだ保留中です。202 はリクエストが処理のために受け入れられたことを示す最終レスポンスですが、結果の準備はまだできていない可能性があります。個別に観測および復元可能な処理においては、通常、202 とステータスリソースの組み合わせのほうが明確です。
2. プロキシが 1xx レスポンスを転送しない場合はどうなりますか？
1xx はオプションの最適化として扱い、正確性を保証する唯一のシグナルとしては決して扱いません。ステータスエンドポイント、SSE、または制御されたクライアントパスを通じて復元可能な状態を提供し、実際の仲介者チェーンをテストします。
3. それでも 102 を使用するのはどのような場合ですか？
エンドツーエンドのスタックがそれを明示的にサポートしており、要件が同じ長時間リクエストに対する暫定的なヒントであり、チームが互換性の境界を受け入れている場合に限られます。クライアント、プロキシ、タイムアウトのエビデンスを記録し、102 がなくても動作する適切なフォールバックを維持します。