PUTとPATCHの違い|使い分けと「消えるPUT」の落とし穴

PUTとPATCHは、どちらも「既存のデータを更新する」ためのHTTPメソッドです。名前も役割も似ているため、「結局どちらを使えばいいのか」「PATCHで作っていた処理をPUTに変えても大丈夫か」といった疑問を持つ方は多いと思います。

結論から言うと、この2つは「一部だけ送っていいかどうか」という一点で決定的に違います。そして、この違いを知らずに実装すると、「一部の項目だけ直したつもりが、他の項目が消えてしまう」という事故が普通に起きます。

関連

GET・POST・DELETEなど他のHTTPメソッドも含めた全体像は、 HTTPメソッド一覧 で一覧にして整理しています。

PUTとPATCHの違いは「一部だけ送っていいか」

PUTとPATCHの違いは、次の1点に集約されます。

例えば、次のようなプロフィールがあるとします。

名前:パイソン太郎 / メール:tanaka@example.com / 自己紹介:よろしくお願いします。

このうち「自己紹介だけを直したい」という場面で、自己紹介の内容だけを送ったとします。

PATCHであれば、自己紹介だけが更新され、名前とメールはそのまま残ります。ところが同じリクエストをPUTで送ると、「データはこれで全部です」と宣言したことになるため、リクエストに含まれていない名前とメールは消えたり、初期値にリセットされたりします

PUTで起きる典型的な事故|「消えるPUT」

実務でよくあるのが、次のようなケースです。

この問題が厄介なのは、実装時のテストでは気づきにくい点です。テスト時に「全項目を含んだリクエスト」を送っていれば正常に動作するため、バグが顕在化するのは「一部の項目だけを更新するUI」を作った後、本番でユーザーが実際に部分更新をした瞬間になりがちです。

つまり、PUTを使う以上は「フロントエンドが常に全項目を送ってくる」という前提を、サーバー側・クライアント側の両方で守り続ける必要があります。この前提が崩れた瞬間に、「消えるPUT」の事故が起きます。

体験|同じ更新なのに、結果はこんなに違う

言葉で説明されてもピンとこないと思うので、実際に手を動かして確かめてみましょう。以下のデモは演出ではなく、「自己紹介」だけを書き換えるリクエストをPUTとPATCHそれぞれで送り、その場でプロフィールの状態を書き換えます(実際の通信は発生しません)。

体験デモ|同じ書き換えなのに結果が違う

自己紹介だけ直したのに、PUTだと名前とメールが消える

「自己紹介」だけを書き換えて、PUTとPATCHそれぞれのボタンで送ってみてください。2つの結果を横に並べて比較できます。

今回書き換えるのは自己紹介だけです。名前とメールには触れていません。

PUT 丸ごと置き換え
名前 パイソン太郎
メール tanaka@example.com
自己紹介 よろしくお願いします。
送信するとここが変わります
PATCH 部分更新
名前 パイソン太郎
メール tanaka@example.com
自己紹介 よろしくお願いします。
送信するとここが変わります

左右どちらのボタンも押して、結果カードを見比べてみてください。

左のPUTを押すと、自己紹介は更新された一方で名前とメールが「(未設定)」に変わったはずです。これが「消えるPUT」です。リクエストに含めなかった項目は、サーバーからすれば「存在しないもの」として扱われ、置き換えの対象になってしまいます。続けて右のPATCHも押してみると、同じ「自己紹介だけ」のリクエストなのに、今度は名前とメールがそのまま残ります。2枚のカードを並べて見比べると、送っていない項目をどう扱うかという一点だけで結果がまったく変わることがはっきりわかります。

POST・PUT・PATCHを一覧で比較

「新規作成」のPOSTも含めて、3つのメソッドを比較すると次のようになります。

メソッド 役割 送らなかった項目 べき等性
POST 新規作成・処理の実行 (新規作成なので該当なし) なし
PUT リソースの丸ごと置換 消える・初期化される あり
PATCH リソースの部分更新 そのまま残る 基本なし

POSTは「新しく作る」という点でPUT・PATCHとは役割そのものが異なりますが、この3つが並んで語られるのは、いずれも「サーバー側のデータを変更するリクエストボディ付きのメソッド」だからです。何を新しく作り、何を置き換え、何を部分的に直すのか——この役割の違いを意識するだけで、API設計時の迷いはかなり減ります。

べき等性の観点では、PUTとPATCHは同列ではない

PUTは「べき等」に分類されます。同じリクエストを1回送っても100回送っても、最終的な状態は同じだからです。先ほどのデモでも、同じ自己紹介の内容でPUTを連打すれば、何度押しても同じ結果に落ち着きます。

一方PATCHは、実装によってべき等になる場合とならない場合があります。「自己紹介をこの内容に書き換える」という実装ならべき等ですが、「自己紹介の末尾に追記する」「カウントを+1する」といった実装にすると、送るたびに結果が変わってしまいます。PATCHを設計するときは、この実装依存の性質を意識しておく必要があります。

べき等性を含めたHTTPメソッド全体の整理は、 HTTPメソッド一覧 でより詳しく解説しています。

実務でどちらを使うべきか|判断基準

関連

そもそもGETとPOSTの使い分けを誤ると、CSRFやログ漏洩といった別の種類の事故にもつながります。 GETとPOSTの違いとセキュリティ もあわせてご覧ください。

まとめ

PUTとPATCHの違いは、「送らなかった項目をどう扱うか」という一点に尽きます。

PUTはリソース全体を丸ごと置き換えるため、一部の項目だけを送ると残りが消えてしまいます。PATCHは送った項目だけを変更するため、部分更新を安全に行えます。この違いを理解しないままPUTで部分更新の処理を作ってしまうと、テストでは気づかず、本番で静かにデータが消えていく事故につながります。

迷ったときは、事故の起きにくいPATCHを基本方針にしつつ、「リソースを丸ごと作り直す」場面に限ってPUTを使う、という判断基準を持っておくと安全です。

顧問契約、開発、プロジェクトのご依頼を承ります。
内容、期間により金額が変動しますのでお気軽にお問い合わせください。

※ 案件によりお受けできない場合もあります。

お問い合わせはこちら →
戻る