HTTPメソッドのアンチパターン集
「動くけど怖い」HTTPの使い方をまとめて避けるためのページです。RFC 9110の意図と、現場での事故例から抜粋しています。
よくあるNGパターン
代表的な誤用と、その理由・回避策です。
アンチパターン一覧
| パターン | 何が問題か | 改善案 |
|---|---|---|
| GETで状態変更 | リンクプレビューやプリフェッチで勝手に実行される。安全性に反する。 | 必ずPOST/PUT/PATCH/DELETEに分離し、GETは副作用ゼロに。 |
| POST万能化 | 更新/削除もPOSTに集約するとキャッシュや中継の最適化が効かない。 | 作成はPOST、置換はPUT、部分更新はPATCH、削除はDELETEに分ける。 |
| DELETEが非冪等 | 二度送ると404/500になるなど、リトライできない。 | 存在しなくても204/200で返す設計にし、冪等性を確保。 |
| PUT/PATCHの条件なし更新 | 同時編集で上書き事故が起きる。 | If-Matchによる楽観ロックを必須にする（412で拒否）。 |
| GETにボディ | 仕様上意味が定義されず、中継やFWが破棄することも。 | パラメーターはクエリに。ボディが必要ならPOST/PUT/PATCH。 |
| POSTでステータス乱用 | 成功でも200だけ、重複でも500など、クライアントが判断できない。 | 201/204/409/412など意味の合うコードを返し、Locationやエラー詳細も添える。 |
| OPTIONSをブロック | CORSプレフライトが落ち、実リクエストに到達しない。 | OPTIONSを許可し、Access-Control-Allow-* を正しく返す。 |
アンチパターンに気づくサイン
「なんとなく動く」状態でも下記の兆候があれば設計を見直すと安全です。
チェックポイント
- ステータスコードが200と500しか使われていない。
- GETを外部から叩かれたときに副作用が出る。
- 重複送信で意図しない二重登録が発生する。
- CORSエラーがブラウザで頻発し、ログには何も残らない（OPTIONSが落ちている）。
- API仕様書にメソッドごとの安全性/冪等性の記述がない。
まとめ
HTTPメソッドは「安全性」と「冪等性」の期待がセットで定義されています。ここで挙げたアンチパターンを避け、RFC 9110に沿った使い分けにするだけで、リトライやキャッシュ、中継の挙動が読みやすくなります。