総合面接：HTTP 410 Gone はリソースのライフサイクルをいつ表現すべきか？

プロンプトと適用範囲

公開APIバージョンとWebリソースが恒久的に削除されます。チームは、移行パスと監査証跡を維持しながら、クライアントによる不要な再試行を停止させたいと考えています。410、404、301/308、および403を比較し、レスポンス、キャッシュ、シャットダウン期間、および監視を設計してください。

これはHTTPセマンティクスと製品ライフサイクルに関する質問です。バージョンや廃止日は仮定であり、市場における主張ではありません。

面接官がテストしていること

「現在利用不可」と「恒久的に削除されたと判明している」を区別できるか。
410がキャッシュやクライアントに与える影響を理解しているか。
移行、認可、プライバシー、監査が一貫した1つのライフサイクルモデルを持っているか。
不明な停止やルーティングのバグを隠すためにステータスコードを使用することを避けているか。

尋ねるべき確認用の質問

リソースは恒久的に削除されたのか、一時的にオフラインなのか、それとも安定したURIに移動したのか？
キャッシュ、検索インデックス、SDKの再試行、またはオフラインクライアントが関係しているか？
保存期間、コンプライアンス、または監査ルールによって削除が制約されているか？
古いクライアントは410およびエラーボディ内の移行情報を理解できるか？
リソースの存在を隠すために、認可されていないユーザーに404を表示すべきか？

30秒での回答

「410は、ターゲットが存在していたことをサーバーが把握しており恒久的に削除されたことを意味します。404は現在の表現が利用できないことのみを示します。安定した代替先が存在する場合は301または308を使用し、認可には403またはセキュリティ上の理由による404を使用します。ドキュメント、SDK、移行期間を通じて廃止を告知し、慎重なキャッシュ制御を行いつつ、固定のエラーコードとドキュメントリンクを含む410を返します。クライアントは無駄な再試行を停止すべきです。削除は監査可能な状態を維持し、廃止トラフィック、キャッシュの挙動、移行の成否を測定します。」

ステップバイステップの設計

1. 状態決定テーブルの構築

二度と提供されない恒久的に削除されたリソースには410を使用します。存在や将来の可用性が不明な場合は404を使用し、リソースに明確な新しいURIがある場合はリダイレクトを使用します。認可失敗を403にするか404に偽装するかは、脅威モデルと開示ポリシーに依存します。

2. 410レスポンスの設計

固定のエラーコード、リクエストID、廃止ドキュメント、および任意の代替ヒントを含めます。機密性の高い削除理由やデータベースの状態は公開しないでください。APIは構造化されたエラーボディを使用でき、Webページはアクセスしやすい移行の説明を提供できます。どちらも機械可読な410セマンティクスを維持する必要があります。

http

HTTP/1.1 410 Gone
Cache-Control: max-age=3600
Content-Type: application/problem+json
Link: <https://api.example/migrations/v1>; rel="deprecation"

3. キャッシュとクライアントの処理

410は、メソッドの定義や明示的なキャッシュ制御に別段の指定がない限り、通常ヒューリスティックにキャッシュ可能です。有効期間を選択する前に、誤った無効化のリスク、CDNの挙動、およびローカルクライアントのキャッシュを評価してください。決定が変更される可能性がある場合は、短期間から始めて徐々に延長します。410を受信したクライアントは、無駄な再試行を停止し、移行またはユーザーへの通知ロジックへ移行する必要があります。

4. 廃止期間の計画

非推奨となる日付をドキュメント、SDK、レスポンスヘッダーで公開し、呼び出し元、バージョン、トラフィックごとに利用状況をセグメント化します。期間中は移行シグナルとともに正常に応答し、その後410を返します。リスクの高い書き込みを先に拒否し、読み取り専用の移行エンドポイントを残すことも可能です。変更を行う前にロールバックのチェックポイントを定義してください。

5. 削除とプライバシーの証跡の保持

410はストレージからの物理的削除を証明するものではありません。リソース識別子、承認情報、削除日時、保持ポリシー、代替エントリポイント、レスポンスバージョンを記録します。削除された機密コンテンツをログに保持してはなりません。コンプライアンスにより遅延削除が必要な場合は、内部での保持とクリーンアップが独自の制御下で継続される一方で、外部には410を返します。

6. 分類された結果の監視

410をリソース、クライアント、SDKバージョン、キャッシュヒット、移行クリックごとに分類し、実際の廃止とルーティングのバグを区別します。404、403、リダイレクトチェーン、再試行ボリューム、サポートチケットと比較します。410が予期せず急増した場合は、キャッシュ有効期間の延長を停止し、調査を行いながら設定をロールバックします。

質の高い模範解答

「まずリソースの状態を確定します。既知の恒久的な削除には410、不明または一時的な不在には404、明確な代替先には301または308、認可には403またはセキュリティ上の理由による404を使用します。ドキュメント、SDK、ヘッダーを通じて移行期間を告知し、慎重なキャッシュ設定のもと、固定コード、リクエストID、ドキュメントリンクを含む410を返します。クライアントは再試行を停止します。削除と保持は個別に監査され、メトリクスによって410の発生元、キャッシュ、移行の成否、ロールバックのトリガーをカバーします。」

よくある間違い

すべての削除に対して410を返す → 一時的または不明な状態が恒久的なものに見える → リソース状態を分類する。
代替先があるにもかかわらず410を返す → クライアントが移行の機会を失う → 301/308とドキュメントを使用する。
410を恒久的にキャッシュする → 誤った廃止を取り消すことが困難になる → リスクに応じてTTLを設定・延長する。
410を物理的削除の証明として扱う → 保持とコンプライアンスが無視される → クリーンアップを個別に監査する。
合計値のみを監視する → 古いSDKのエラーが隠れたままになる → バージョン、リソース、キャッシュごとにセグメント化する。

フォローアップの質問と回答

410と404の本質的な違いは何ですか？

410は、リソースが存在していたこと、そしてそれが恒久的に削除されたことをサーバーが確認していることを示します。404は、リソースが存在したかどうかも、将来現れる可能性があるかどうかも示しません。410を選択することで、再試行、キャッシュ、および移行動作に関してより強い保証を与えることになります。

410に代替リンクを含めることはできますか？

はい、ドキュメントや移行エントリポイントを提供することは可能ですが、代替先が現在のリソースであるかのように装ってはなりません。クライアントは依然として認可、バージョン、およびデータマッピングを再確認する必要があります。

なぜ認可されていないユーザーが404を受け取る場合があるのですか？

リソースの存在を明らかにすることが機密情報の漏洩につながる場合、サーバーはその脅威モデルに基づいて404で存在を隠すことがあります。認可された呼び出し元は、依然として一貫性があり監査可能なライフサイクルセマンティクスを受け取る必要があります。