API設計の教科書（RESTful API）を開くと、リソースの取得にはGET、作成にはPOST、更新にはPUTやPATCH、削除にはDELETEを使い分けるのが「美しく正しい設計」とされています。
しかし、実際のWeb開発現場や歴史あるWebアプリケーションを見てみると、「実質GETとPOSTしか使われていない」「更新も削除もPOSTで済ませている」 というケースが少なくありません。
なぜ、せっかく定義されているHTTPメソッドが使われない（敬遠される）ことがあるのでしょうか？その理由を、歴史・HTMLの制約・インフラセキュリティ・運用の現実 の4つの視点から紐解きます。
理由1. HTMLフォーム（<form>タグ）がGETとPOSTしかサポートしていない
最も根本的かつ歴史的な理由は、HTMLの仕様にあります。
Webの基本であるHTMLの<form>タグが対応しているmethod属性は、現在でもGETとPOSTの2種類のみです。
<!-- これは動きます -->
<form method="POST" action="/user/1">
<!-- 仕様上、PUTやDELETEは指定できません（動作しません） -->
<form method="DELETE" action="/user/1"> そのため、JavaScript（Fetch APIやAjax）を使わない標準的なWebページ（SSRや従来のMVCフレームワーク）では、削除ボタンを押しても「内部的にはPOSTリクエストで送信する」しかありませんでした。この歴史的背景から、「Web開発＝GETとPOSTで完結させる」という文化が長年根付いたのです。
※Ruby on Railsなどのフレームワークでは、<form>内に <input type="hidden" name="_method" value="DELETE"> のような疑似的なパラメータを持たせることで、内部的にDELETEやPUTへルーティングする工夫（Method Override）をして対応してきた経緯があります。
理由2. 企業ルーターやWAF（セキュリティー機器）による遮断
実務・エンタープライズ領域で非常に大きいのがネットワークやセキュリティの制約です。
企業内のネットワーク（社内LAN）や、Webアプリケーションの手前に置かれるWAF（Web Application Firewall）、プロキシサーバーの設定によっては、安全のために「GETとPOST以外のHTTPメソッドを遮断する」というルールが適用されていることがあります。
- 理由： 昔の古いWebサーバーにおいて、
PUTやDELETEが許可されていると、第三者にサーバー上のファイルを直接削除されたり上書きされたりする脆弱性につながるリスクがあったため。
開発環境（localhost）ではPUTやDELETEが問題なく動作していても、本番環境やクライアントの通信環境に持っていった途端に「特定のお客さんの環境だけエラー（403 Forbidden や 405 Method Not Allowed）になって繋がらない」 という問題が発生することがあります。
このトラブルを回避するため、「最初からトラブルの起きないPOSTで統一しておこう」というインフラ・運用主導の判断が働くのです。
理由3. PUTとPATCHの「使い分け」の難しさと複雑さ
更新処理に使われるPUTとPATCHですが、この2つの明確な違いをチーム全員が正しく理解して運用するのは意外と大変です。
- PUT（置換）： リソース全体を置き換える。送信されなかった項目は「削除（null化）」されるのが本来の定義。
- PATCH（差分更新）： 変更したい一部の項目だけを更新する。
例えば、「ユーザーのプロフィール更新」で一部の項目だけを送信したい場合、本来はPATCHを使うべきですが、PUTで一部更新の実装をしてしまっているAPIも少なくありません。
さらに、PATCHは2010年にRFC 5789として後から追加された標準仕様であるため、他のメソッドに比べて歴史が浅いという側面もあります。
このような「使い分けの曖昧さ」や「実装ミスによるデータ消失リスク（PUTで全上書きしてしまう事故など）」を避けるため、「更新処理は一律POSTにして、何を変更するかはリクエストボディで表現する」 という設計を選ぶ開発現場も多く存在します。
理由4. API設計の「シンプルさ（RPC的アプローチ）」の優先
APIの設計思想には、大きく分けて2つの潮流があります。
- REST的思考： URLは「リソース（モノ）」を表し、操作は「HTTPメソッド（動詞）」で表す。
- 例:
DELETE /users/123
- 例:
- RPC（Remote Procedure Call）的思考： URLに「行いたい操作（動詞）」を含め、メソッドは
POSTに統一する。- 例:
POST /users/123/deleteまたはPOST /users/delete
- 例:
現代のWebサービス（特にSlackやDiscordのAPI、GraphQL、gRPCなど）では、RPC的なアプローチやPOSTへの統一がよく採用されます。
理由として、URLとPOSTパラメータだけで「何をするリクエストなのか」が明白になり、HTTPメソッドの仕様に依存せずバックエンド側のルーティングやログ解析がシンプルになるというメリットがあるためです。
まとめ：結局どちらを使うべきなのか？
| 手法 | メリット | デメリット |
| RESTful（GET/POST/PUT/PATCH/DELETEを使い分ける） | ・HTTPの仕様に忠実で美しく標準的 ・CRUD操作が直感的に理解しやすい | ・古く厳しい通信環境で遮断されるリスクがある ・フロント側の実装（HTML標準機能）だけでは扱えない |
| POST統一（GETとPOSTのみ） | ・どのネットワーク・ブラウザでも確実に通る ・WAFやプロキシの設定に悩まされにくい | ・URL設計に動詞が増え、RESTの原則からは外れる ・べき乗性（Idempotency）などのHTTPの恩恵を自前で意識する必要がある |
「GET/POSTしか使わない」というのは、技術的な手抜きではなく、「Webブラウザの制限」「ネットワークセキュリティ」「運用の確実性」という実務上の理由から選ばれた現実的なプラクティスでもあります。
新規プロダクトでモダンなSPA（React/Vueなど）と堅牢なAPIを作るならPUT/PATCH/DELETEを活用したRESTful設計は非常に有力ですが、社内システムや多様なクライアントを想定する環境では、あえてPOSTに寄せる設計も合理的な選択肢と言えます。
コメント