はじめに

2022年の5月にSIerからWeb系自社開発会社に転職したありひとと申します。
前職ではミッションクリティカルな社会インフラを支えるシステムだったこともあり、使っている技術が枯れまくったものでした。
したがって、前職と今とでは扱っている技術スタックが全く違っており日々勉強の毎日です。

今回は、なんとなく知っていたけど、前職の実務では使ってこなかったREST APIに関連して「POST」と「PUT」の違いについてまとめます。

ちなみに前職では、REST APIではなくSOAP通信がメインで使わていました。

この記事でわかること

REST APIの文脈における「POST」と「PUT」の違いについて理解してもらうのが、この記事のゴールです。
そもそもREST APIって何？とかSOAPとの違いは？ってのは別記事でまとめる予定です。

POSTとPUTはどちらも登録

この手の「〜の違い」とかって自分でも何回も調べてしまうのですが、よくある説明で「POSTは新規登録、PUTは更新」というのがあります。これは誤りです。
結論を述べると

「POST」と「PUT」はどちらも「登録」
ただしリソースの指定方法が違う

1ポチ目はそのまんまですが、2ポチ目はどういうことか？具体的にみていきます。

書籍の登録をする場合

まずREST APIというのは、ざっくり言えば「HTTPプロトコルとHTTPのメソッドを使って、サーバ上のリソースにアクセス・操作する仕組み」だと思ってください。
「リソース」というのがまた曖昧な表現ですが、例えば読んだ本を管理するWEBサービスがあったとすれば、その書籍のデータひとつひとつが「リソース」です。

前述したように「POST」と「PUT」はどちらもリソースを登録するときの操作ですが、そのときリソースの識別番号の体系を要求側が意識するか/しないかが違ってきます。

POSTの場合

例えば、POSTを使って書籍データをサーバに登録しようとした場合、下記のようなHTTPリクエストラインになります（ヘッダ、ボディは省略）。

POST https://hogehoge.com/books

この場合、登録した書籍データがどんな識別番号体系で管理されるかを要求する側（クライアント）は事前に知っている必要は必要ありません。サーバ側の方で識別番号を発行し、登録してくれます。
今回の例でいうと、この書籍管理サービスでは書籍データを4桁の数字で管理するつくりになっているようですが、POSTであればクライアントはそのことを知らずとも書籍を登録することができます。

PUTの場合

では、PUTの場合はどうなるかというと、お察しのとおりクライアント側が識別番号を指定する必要があります。

PUT https://hogehoge.com/books/1234

すでに識別番号1234で書籍データが登録されている場合に、同じように識別番号1234で別の書籍を登録しようとすれば、サーバ側の情報を書き換えることができます。
だから「POSTは新規登録、PUTは更新」と説明されるんですね。
実際は「POST」も「PUT」も「登録」なのですが、「PUT」は識別番号を指定できるがゆえに既存のデータに対して登録し直し＝更新ができる、というわけですね。

編集後記（余談）

今回、記事内のシーケンス図をつくるためにmermaidという言語を使ってみました。
はじめて使ってみたのですが、シーケンス図に限らずフロー図、ER図などをとても簡単かつ直感的に書くことができ、とてもよかったです。

参考文献

『現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法』：コードの実装例は少なくやや抽象的な記述が多く感じるかも知れないが、オブジェクト指向パラダイムの言語を使って開発していくうえで重要な概念について網羅的かつわかりやすく書かれている