HTTPリクエストメソッドにPUTを使う利点は何でしょうか？

Question

お世話になっております。POSTではなくPUTを使うメリットについて有識者のご意見を伺いたいです（PUTはどういう時に使うのかの質問ではありません）。
POSTとPUTの使い分け自体は「べき等性があるAPIはPUTとすべき」という理解ですが、「そういうルールを取り決めた方が分かりやすいから」という以外にPUTを使うメリットがよく分かっていません。
大抵の場合、新規登録のURLには対象データを示すidが入っておらず更新なら何を更新するかのidが入っているので、POST1本で十分では？と思ってしまいます。

何ならPUTを使うデメリットの方があるんじゃないかと思っておりまして、屁理屈みたいですが
普通のデータAがあった時、新規登録は POST /data_a で更新は PUT /data_a/:ID になりますが、
大事なデータBがあり、データBは更新時にメールが飛ぶものとすると、更新はPUTのままで正しいのか？とかPOSTにしたらしたで他のデータもPOSTに揃えた方が分かりやすいんじゃないか？とか、話がややこしくなりそうな気がしています。

またこれも細かい話ですが、APIを使う画面を作成している際、新規登録画面と編集画面は同じ画面で作ることも多く、また新規も編集もほぼ同じパラメーターになるのでidを渡すか渡さないか程度の分岐だけになるはずのところ、POSTとPUTを使い分けている場合は呼び出すメソッドの分岐も増えるのがいまいちスマートでないなと思っています。

もちろんそういったルール付け自体に価値があることは重々承知しているのですが、それ以外にPUTを使うメリットは他に何か無いのでしょうか？
例えばパフォーマンス面で何か良いとか、セキュリティ上PUTの方が良いとか(CSRF関連は当然対策するとして)、そういった何か明確なメリットがあれば教えていただきたく存じます。

Answer 1

疑問に思ったときは定義に立ち返って見るのも良いと思います。

https://tools.ietf.org/html/rfc7231#section-4.3.4

一部引用します。

The fundamental difference between the POST and PUT methods is

highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server.

idempotent （冪等性）という単語が出てくるように、 内容の同じ PUT リクエストを実行しても対象のリソースの状態がリクエスト後の結果として同じになるようにしましょう、ということを期待しているわけですね。
（世の中のすべての PUT リクエストがこのように実装されているかの保証は無いですが）

Comments

[reimer0204]

ご回答ありがとうございます。また、分かりにくい質問で申し訳ございません。
PUTがそのような定義なのは存じておりまして、その上でPOSTを使うと何か問題があるのか、PUTで実装した方が設計やコーディングがややこしくこともあるのに、「そう取り決められているから」以上の理由が何か無いのか、ということをお伺いしたいなと思っています。

[mather]

そういった話であれば、懸念点をもう少し具体的にしたほうが良いと思います。

> 新規登録のURLには対象データを示すidが入っておらず更新なら何を更新するかのidが入っているので
POST /data_a/:id という意味でしょうか？POSTメソッドにしたいなら特に止める理由はないですね。
「内容はPUTと同等である」という意図が開発者の間で理解されているならいいのではないでしょうか。

> 普通のデータA, 大事なデータB
リソースの重要度はよくわかりませんが、PUTだとメールが飛ばないとかのルールは一切無いのでリソースが更新されたときにどのような処理が実行されるべきかは開発者同士で決めてください。

結果としてメリットは「PUTには冪等性が想定されている」共通認識があることで、開発者や利用者がHTTPリクエストによって何が起こるか想像しやすくなることにあると思います。

[mather]

> 新規登録画面と編集画面は同じ画面で作ることも多く、
それは開発者によって違うでしょうね。

> また新規も編集もほぼ同じパラメーターになるのでidを渡すか渡さないか程度の分岐だけになるはずのところ、
かなり重要な分岐だと思いますよ？

> POSTとPUTを使い分けている場合は呼び出すメソッドの分岐も増えるのがいまいちスマートでないなと思っています。
使い分けずに呼び出すって具体的にどうするんでしょうか？
「こっちのほうがスマートだと思う」という提案を質問に追記しましょう。

[reimer0204]

ご返信ありがとうございます。また懸念点が分かりにくく申し訳ございません。
何か具体的な懸念点があるわけではなく、「そういうものだから」以外にPUTを使うメリット、がお伺いしたかった点になります。

「ルールに則ったほうが皆に分かりやすい以上のメリットは無い」ということですね。ありがとうございます。

[reimer0204]

すみません、返信が入れ違いになってしまいました。

> 「こっちのほうがスマートだと思う」
まとめ方がわかりにくくすみません。POSTだけで実装していれば、メソッドを指定する分の分岐は不要になるので、そちらを気にしております。
もちろんたった1変数の話ではありますが…

[mather]

> POSTだけで実装していれば、メソッドを指定する分の分岐は不要になる
method = resource.id == null ? "POST" : "PUT";
のような分岐をせずに POST 固定にできる、というイメージでしょうか？
僕自身が実装することを考えれば、そういった細かい部分を意識せずに済むように「新規リソースを作成する」「既存リソースを更新する」をそれぞれ関数にして呼び出します。（その内部に共通した処理があれば共通化もできるでしょうけど）

[reimer0204]

はい、そちらのお話になります。
すみません、やり取りしているうちに様々なAPIのケースが想定されることに気付いたのですが、当方が扱っているのは新規登録も更新もパラメーターはidを指定するかどうかの差異のみでしたのでこのような質問をしておりましたが、そもそもそれ以上の差異があるならご提示いただいたように呼び出す側も関数を2つ作るような話になると思います。
知識不足で提示すべき情報が不足しておりましたこと、大変失礼いたしました。
PUT自体の利点については理解いたしましたので、こちら解決とさせていただきます。

Answer 2

• PUT - HTTP | MDN

「PUT はべき等であり、呼び出し回数が1回でも複数回でも同じ効果になります」とのことです

べき等については冪等 - Wikipediaを参照ください

Comments

[reimer0204]

ご回答ありがとうございます。また言葉足らずですみません。
べき等な効果を持つAPIはPUTとすべき、というのは理解しておりまして、その上でそれをPOSTで作ってはいけない理由、PUTとした方が良い理由を探しております。
元質問に記載した通り、PUTを使った方がコーディング上のデメリットがある気がしておりまして、「そう取り決められているから」以外の理由があれば教えていただきたく存じます。