HTTPメソッドのアンチパターン集
「動くけど怖い」HTTPの使い方をまとめて避けるためのページです。RFC 9110の性質と、実装時に起こり得る問題を整理しています。POSTを選ぶこと自体が仕様違反とは限りません。
よくあるNGパターン
代表的な誤用と、その理由・回避策です。
アンチパターン一覧
| パターン | 何が問題か | 改善案 |
|---|---|---|
| GETで状態変更 | リンクプレビューやプリフェッチで勝手に実行される。安全性に反する。 | 変更を要求する操作はPOST/PUT/PATCH/DELETEなどへ分離。アクセスログなどの付随動作とは区別する。 |
| POSTの再送条件が不明 | POSTは広い処理に使えるが、冪等性は自動的に保証されない。 | 意味が合う場合はPUTなどを選ぶ。POSTでは二重実行防止や状態照会の契約を明確にする。 |
| DELETEの再実行で別の対象を削除 | 同じ要求で「次の1件」まで消すと、繰り返した効果が1回と異なる。 | 対象を固定する。初回204・再要求404というコードの違いだけでは非冪等とはいえない。 |
| PUT/PATCHの条件なし更新 | 同時編集で上書き事故が起きる。 | 競合検出が必要なら強いETagとIf-Matchを採用し、条件不成立は412、必須条件の欠落は428などで伝える。 |
| GETにボディ | 仕様上意味が定義されず、中継やFWが破棄することも。 | 通常はクエリを使う。本文を要する検索なら処理用POSTを設計する。PUT/PATCHを読み取り用に流用しない。 |
| POSTでステータス乱用 | 成功でも200だけ、重複でも500など、クライアントが判断できない。 | 201/204/409/412など意味の合うコードを返し、Locationやエラー詳細も添える。 |
| OPTIONSをブロック | CORSプレフライトが落ち、実リクエストに到達しない。 | 公開方針に合うOrigin・メソッド・ヘッダーだけ許可する。CORSは認証やCSRF対策の代わりにはならない。 |
アンチパターンに気づくサイン
「なんとなく動く」状態でも下記の兆候があれば設計を見直すと安全です。
チェックポイント
- ステータスコードが200と500しか使われていない。
- GETの巡回で購入や削除などの変更操作が実行される。
- 重複送信で意図しない二重登録が発生する。
- CORSエラーで失敗する。開発者ツールでOPTIONSの有無と応答を確認する。実リクエスト送信後に応答の読み取りだけ拒否される場合もある。
- API仕様書にメソッドごとの安全性/冪等性の記述がない。
まとめ
再送時はコードが同じかより、意図しない追加処理が起きないかを確認しましょう。メソッドの性質、更新競合の防止、CORSの仕組みへ進むと対策を選びやすくなります。
仕様・関連資料
RFC 9110 §9 / RFC 9110 §13 / RFC 6585 §3 / Fetch: CORS protocol