バックエンド面接：なぜ 405 Method Not Allowed は Allow を返さなければならないのか？

質問

あなたはファイル API を保守しています。GET /v1/files/:id はファイルを読み取りますが、クライアントが同じリソースに対して POST または DELETE を送信しました。面接官は、レスポンスを設計し、405、404、403、OPTIONS、および CORS プリフライトの違いを説明するよう求めています。ルーティングのマッチング、Allow ヘッダー、エラーボディ、テスト、およびロールアウトについて説明してください。

コンテキストと制約

リソースルートは具体的なファイルにマッチしますが、現在有効になっているのは GET と HEAD のみです。
SDK のバージョン不一致によって無効なメソッドが発生する場合があり、プロキシがそれを書き換えたりインターセプトしたりする可能性があります。
呼び出し元は原因を診断できるレスポンスを必要としており、無効化されたメソッドを利用可能として通知してはなりません。
リソースの存在自体が機密情報である場合、チームは API コントラクトに文書化された一貫性のある 404 隠蔽ポリシーを使用する場合があります。

面接官が見ているポイント

リソースマッチングとメソッドディスパッチの分離

まずホスト、パス、バージョン、リソース識別子をマッチングし、その後にリソースの許可されたメソッドセットを検索します。パスが存在しない場合は 404 を返し、パスは存在するがメソッドがそのセットに含まれていない場合は 405 を返します。認可はセキュリティポリシーに従います。認証された呼び出し元に権限がない場合は 403 を受け取る可能性があります。すべての認可失敗を 405 に変換してはなりません。

405 には必ず Allow を含める必要がある

405 は、サーバーがリクエストメソッドを認識しているものの、ターゲットリソースがそれをサポートしていないことを意味します。レスポンスには Allow を含め、そのリソースで現在サポートされているメソッドをリストアップする必要があります。例：

http

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS
Content-Type: application/problem+json

{"type":"about:blank","title":"Method Not Allowed","status":405,"detail":"Use one of the methods listed in Allow."}

Allow はリソースの機能（ケーパビリティ）を記述します。これはブラウザのクロスオリジンポリシーに関与する CORS の Access-Control-Allow-Methods とは異なり、405 によって表現される HTTP メソッドコントラクトを代替することはできません。

OPTIONS を個別にモデル化する

OPTIONS は通信オプションを問い合わせることができます。ブラウザの CORS プリフライトも Origin と Access-Control-Request-Method を送信します。プリフライトが成功するかどうかは、CORS レスポンスヘッダーと認証ポリシーに依存します。すべての OPTIONS リクエストを 405 に変換したり、Allow を CORS 認可リストとして扱ったりしてはなりません。

回答前の確認質問

リソースは実際に存在しますか？存在しない場合は 404 を使用します。セキュリティポリシーによって存在を隠蔽する場合は、一貫して 404 を返すかどうかを確認します。
許可されるメソッドは、テナント、リソースの状態、または API バージョンによって異なりますか？この回答によって、Allow の生成に使用されるコンテキストとキャッシュキーが変わります。
ゲートウェイは未知のメソッドを書き換えますか？また、Allow 生成の責任は誰にありますか？この回答によって、デバッグの境界と Single Source of Truth（信頼できる唯一の情報源）が定義されます。

30秒の回答フレームワーク

「パスはマッチしましたが、メソッドがリソースの機能セット外であるため、405 を返し、実際にサポートされているメソッドを Allow にリストします。パスが存在しない場合は 404、認可拒否は 403 ポリシーに従い、OPTIONS と CORS プリフライトは個別のヘッダーを使用します。最後に、メソッドマトリックス、実際のゲートウェイパスでのテスト、ロールアウトメトリクスで締めくくります。」

ステップごとの詳細な回答

各リソースルートの許可メソッドを監査可能なレジストリで定義し、ルーターがディスパッチと Allow 生成の両方にその同一のレジストリを使用するようにします。POST /v1/files/123 については、リソースが存在し POST が登録されていない場合は 405 を返します。123 が存在しない場合は 404 を返します。マッチしたリクエストが認可ポリシーによって拒否された場合は 403 を返します。HEAD は多くの場合 GET の読み取り機能に従いますが、フレームワークの実際の挙動が信頼できる情報源となります。

エラーボディは、スタックトレースや内部ルーティングの詳細を公開することなく、安定したステータス、タイトル、実用的な説明を提供する必要があります。Allow には実際に有効化されているメソッドのみをリストします。ロールアウト中に、デプロイされていない書き込み機能を通知してはなりません。セキュリティポリシーによってリソースの存在を隠す場合は、404 と 405 の選択基準、ログフィールド、クライアントのリトライ動作を文書化します。

質の高い模範解答

「まずルーターにファイルが存在するかどうかを判断させ、次に単一のメソッドレジストリからディスパッチします。存在するファイルに対して未登録の POST を受信した場合、405 を返し、GET, HEAD と真にサポートされている OPTIONS を Allow に設定します。ファイルが存在しない場合は 404 を返し、403 については認可ポリシーに従います。CORS プリフライトは Access-Control-Allow-Methods を使用し、Allow は使用しません。ゲートウェイとアプリケーションの間でヘッダー生成の担当者を 1 つに定めます。コントラクトテストで各ステータスとメソッドセットを検証し、ロールアウトではメソッドごとの 405 を監視します。」

よくある間違い

存在するパスに対してサポートされていないメソッドが使われた際に 404 を返し、呼び出し元が不正な URL なのか不正なメソッドなのかを区別できなくなる。
Allow なしで 405 を返し、クライアントがサポートされているメソッドを発見できなくなり、HTTP セマンティクスに違反する。
Allow の代わりに Access-Control-Allow-Methods を使用し、HTTP 機能とブラウザのクロスオリジン権限を混同する。
すべての認可失敗を 405 として扱い、セキュリティ監査、モニタリング、クライアントの挙動を混乱させる。
ゲートウェイとアプリケーションが異なる Allow セットを生成し、プロキシキャッシュ後に不整合なレスポンスを生み出す。

エラー、原因、修正

405 を汎用的なエラーとして扱ったり、Allow を省略したり、CORS ヘッダーを Allow として使用したりすると、呼び出し元は次のアクションを取れなくなります。まずリソースのマッチングを行い、単一のメソッドレジストリからステータスとヘッダーを生成し、404、403、405、およびプリフライトを個別にテストすることでフローを修正します。

本番環境での実装

ルートとプロキシの連携

アプリケーションの 405 および Allow をゲートウェイ経由で透過させるか、ゲートウェイ側の単一の責任者を定義して重複した上書きを防止します。API バージョンごとに、キャッシュ、冪等性、認証、リトライ要件を含むメソッドマトリックスを維持します。プロキシが未知のメソッドを GET にダウングレードしている場合は、まずそのポリシーを修正してください。そうしないと、アプリケーションは実際のメソッドを確認できません。

オブザーバビリティと互換性

ファイル内容をログに記録することなく、リクエストメソッド、正規化されたパス、ルートバージョン、レスポンスステータス、および最終的な Allow セットを記録します。405 を受け取ったクライアントは、同じメソッドでの盲目的なリトライを停止し、コントラクトでサポートされているメソッドを使用するか、SDK をアップグレードする必要があります。レガシーなクライアントに対しては、バージョン管理された変更を通じて動作を厳格化する前に、ログやドキュメントで誤用状況を観察します。

検証チェックリスト

コントラクトテスト

登録されたメソッドの成功、未登録メソッドに対する 405、存在しないパスに対する 404、認可拒否に対する 403、および Allow と実際のルートとの一致をカバーする、すべてのリソースのメソッドマトリックスを作成します。ステータス、ヘッダーのメソッドセット、Content-Type、エラーボディフィールドをアサートします。

統合テストとリグレッションテスト

実際の HTTP クライアントを使用して、ゲートウェイ、ロードバランサー、およびアプリケーションの動作を総合的に検証します。OPTIONS と CORS プリフライトを個別にテストし、Access-Control-Allow-Methods が Allow を置き換えていないことを確認します。ロールアウト中は、405 の発生率、メソッドの分布、およびエラーボディのパース失敗についてアラートを設定します。

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

405 の代わりに 404 を返せるのはどのような場合ですか？

パスが本当に存在しない場合、またはセキュリティポリシーによって意図的にリソースの存在を隠蔽する場合に 404 を返します。そのリソースクラスに対してその選択を一貫して適用し、クライアント、ログ、モニタリング向けに文書化します。ノードによってランダムに 404 または 405 を返してはなりません。

Allow には常に OPTIONS を含める必要がありますか？

リソースが実際に OPTIONS を受け入れる場合にのみ含めます。フレームワークが OPTIONS を自動的に処理する場合は、そのレスポンスがアプリケーションのルートコントラクトと一致していることを確認してください。見た目の完全性のためだけに実装されていないメソッドを追加しないでください。

動的な機能はどのように機能すべきですか？

メソッドの機能がテナント、バージョン、またはリソースの状態によって異なる場合、現在のリクエストコンテキストから Allow を生成し、すべての機能ディメンションをキャッシュキーに含めます。より安全なデフォルトは、405 の中間キャッシュを制限するか、明示的なキャッシュポリシーを設定することです。

評価基準

セマンティクスの正確性：405 が適用されるタイミングと、なぜ Allow が必須であるかを説明できる。
明確な境界：404、403、OPTIONS、CORS、およびセキュリティ上の隠蔽を区別できる。
実践的な実装：具体的なレジストリ、プロキシ、エラーボディ、オブザーバビリティの選択肢を提示できる。
完全な検証：メソッドマトリックス、実際の HTTP パス、ロールアウトメトリクス、リグレッションをカバーしている。
リスク認識：存在しないメソッドの誤通知、情報漏洩、ゲートウェイとアプリケーション間の不一致を防ぐことができる。

参考資料

MDN: 405 Method Not Allowed
MDN: Allow header
Postman: HTTP Error 405
JustAcademy: REST API interview questions

回答のコツ

「リソースはマッチしたが、メソッドがサポートされていないため 405 を返す」から始め、実際の Allow セットを提示します。404、403、OPTIONS、CORS を区別し、メソッドマトリックスのテストとプロキシの一貫性で締めくくります。

1行のまとめ

405 はリソースとメソッドの組み合わせが無効であることを示し、Allow はどのメソッドが現在有効であるかをクライアントに伝えます。これらが合わさることで診断可能な HTTP コントラクトが形成されます。