「405 Method Not Allowed」を侮るな：API設計とトラブルシューティングの作法
システム運用をしていると、ログファイルの中にポツンと現れる「405」という数字。多くのエンジニアは「ああ、またメソッドの指定ミスか」と軽く流してしまいがちです。しかし、HTTP/1.1の仕様を紐解くと、このエラーコードは単なる拒絶ではなく、「サーバーとクライアントの対話」において極めて重要なマナーを規定していることがわかります。
今日は、API設計者やインフラエンジニアなら絶対に押さえておくべき「405 Method Not Allowed」の深層と、それに付随する`Allow`ヘッダーの正しい作法について、現場の視点から解説します。
—
1. 405エラーの本質：サーバーからの「正しい案内」
RFC 9110（旧RFC 7231）において、405ステータスコードは「リクエストされたメソッドが、そのターゲットリソースで許可されていない」ことを示すために定義されています。
ここで勘違いしてはいけないのが、「405を返すサーバーは、該当リソースに対して何ができるのかをクライアントに教える義務がある」という点です。これを怠ると、クライアント側のデバッグは難航し、無駄なリクエストが繰り返されることになります。
必須の作法：Allowヘッダー
405エラーを返す際、サーバーは必ず`Allow`ヘッダーを含める必要があります。これがない405レスポンスは、仕様を満たしていない「不親切な回答」です。
HTTP/1.1 405 Method Not Allowed
Date: Wed, 22 May 2024 10:00:00 GMT
Content-Type: text/plain
Allow: GET, HEAD # ← これが重要！「GETとHEADなら受け付けるよ」という提示
—
2. 現場で役立つ検証手順：curlを使ったデバッグ
トラブルシューティングの際、ブラウザのデベロッパーツールも便利ですが、やはりCLIでの確認が最も信頼できます。`curl`を使って、特定のメソッドが拒否される挙動を確認してみましょう。
対象エンドポイントに対して、あえて許可されていない DELETE を投げてみる
curl -v -X DELETE https://api.example.com/items/123
レスポンスヘッダーに注目
< HTTP/1.1 405 Method Not Allowed
< Allow: GET, POST
もしここで`Allow`ヘッダーが返ってこない場合、それはNginxやApache、あるいはAPIゲートウェイのコンフィグで「エラーページのカスタム設定」が漏れている可能性が高いです。
---
3. 実装上の落とし穴：Nginxでの設定ミス
インフラエンジニアがよく遭遇するのが、リバースプロキシの設定で特定のメソッドを制限した際、適切にエラーをハンドリングできていないケースです。
例えば、Nginxで特定のディレクトリに対して`POST`のみを許可し、それ以外を拒否する場合、以下のような設定が必要になります。
location /api/resource {
# limit_except を使った制御
limit_except GET {
deny all;
}
# ここで 405 が返されるが、適切に Allow ヘッダーが送られているか確認が必要
# もしエラーページ設定で 405 を隠蔽している場合は要注意
}
シニアからのTips：
稀に、セキュリティ上の理由（Fingerprinting対策）で「Allowヘッダーをわざと消す」という判断をする現場もありますが、それはクライアント側の実装負荷を増大させるトレードオフであることを理解しておいてください。基本は「仕様に従い、Allowを返す」のがベストプラクティスです。
—
4. クライアントサイドでのハンドリング
フロントエンド開発者が`fetch` APIを使っている場合、405エラーは例外（`throw`）として扱われません。`response.ok`プロパティを確認するフローが不可欠です。
async function fetchData() {
const response = await fetch(‘/api/data’, { method: ‘DELETE’ });
if (!response.ok) {
if (response.status === 405) {
// Allowヘッダーを読み取って、次に何をすべきか判断する
const allowedMethods = response.headers.get(‘Allow’);
console.warn(`このリソースで許可されているメソッド: ${allowedMethods}`);
// ここでUIに適切な警告を出す等のリカバリーを行う
return;
}
throw new Error(‘予期せぬエラーが発生しました’);
}
}
—
まとめ：プロフェッショナルの視点
405エラーは、単なる「拒絶のサイン」ではありません。サーバーがそのリソースに対して提供できるインターフェースを明確に示すためのコミュニケーションツールです。
- API設計者へ： 405を返す際は、必ずサポートしているメソッドを`Allow`ヘッダーで明示すること。
- インフラ運用者へ： プロキシやWAFの設定で405を返す際、ヘッダー情報が欠落しないよう疎通確認を行うこと。
- 開発者へ： 405を受け取ったら、まずは`Allow`ヘッダーを確認し、APIの仕様書と突き合わせる習慣をつけること。
ネットワークの挙動を深く理解することは、システムの堅牢性を高めるだけでなく、チーム全体の開発体験（DX）を向上させることにも直結します。今日からログに流れる「405」を見る目が少し変わるはずです。
次回の記事では、HTTP/2以降でこの「メソッド」という概念がどう変化したのか、あるいはステータスコードの設計哲学についてさらに深掘りしていこうと思います。それでは、良いエンジニアリングを。
コメント