質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
REST

REST(Representational State Transfer)はwebアプリケーションの構築スタイルの一種です。HTTP GET/POSTによってリクエストを送信し、レスポンスはXMLで返されます。SOAPのようなRPCの構築と比べるとサーバからクライアントを分離することが出来る為、人気です。

Q&A

1回答

14166閲覧

REST APIにおいて更新のみを行うPUT処理は適切か

takenyaan

総合スコア119

REST

REST(Representational State Transfer)はwebアプリケーションの構築スタイルの一種です。HTTP GET/POSTによってリクエストを送信し、レスポンスはXMLで返されます。SOAPのようなRPCの構築と比べるとサーバからクライアントを分離することが出来る為、人気です。

0グッド

0クリップ

投稿2018/05/22 15:07

リソース指向アーキテクチャに基づいてRESTfulなAPIの設定を行なっております。

今回リソースの新規作成は一律POSTによって行う想定です。
(=リソースの一意なIDの払出しはサーバサイドで実施)
この前提のもと、作成したリソースの全体更新を行う場合は、
PUTメソッドを利用すべきでしょうか、それともPATCHメソッドを利用すべきでしょうか。

PUTメソッドを利用する場合

リソースの全体更新を行う場合であればPUTメソッドが適切に思えますが、
IDの払出しはサーバでコントロールしたいため、存在しないIDが指定された場合に新規登録は行いたくありません。
存在しないIDに対してPUTが行われた時に、例えば404(NOT FOUND)等のエラーを返すことは可能ですが、
この対応が冪等性のあるPUT処理として適切ではないような気がします。

PATCHメソッドを利用する場合

更新処理であればPATCHメソッドが利用可能だと考えています。
一方でPATCHは部分更新を行うためのものであり、全体更新処理に利用するのが適切か悩ましいところです。

皆さまの知見、ご意見頂けますと幸いです。

補足:Github APIやQiita APIはPATCHを利用していますね。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

・リクエストにそのリソースの情報を全て乗せて送信する
・更新処理でオートインクリメントや更新日時の自動更新などが発生しない(冪等)

上記であればPUT。

・リクエストにそのリソースの情報を部分的(Nameだけなど)に送信する
・更新処理でオートインクリメントや更新日時の自動更新などが発生する(非冪等)

上記であればPATCHじゃないでしょうか。

更新のみを行うPUTは適切なのか

以下のサイトから抜粋します。
HTTP Methods [ RESTful APIs Verbs ] – REST API Tutorial

PUTのセクションで

if resource does not exist then API may decide to create a new resource or not

「該当のリソースがなければ、APIは新しいリソースを作るかもしれない(may)
とあるので、別にCREATEしなくてもいいんじゃないでしょうか?

また、このサイトのSummaryのセクションでのPUTの説明では

200 (OK) or 204 (No Content). Use 404 (Not Found), if ID not found or invalid.

「200か204。IDが見つからないか無効な場合は404を使います」
とあるので、やはりCREATEせずに404を返してもいいのかなと思います。

UPDATE or 404 は冪等ではないのか

これは冪等であると言えるんじゃないでしょうか?
以下は僕の私見なのですが、「冪等」はクライアントに対して同じ結果を返すというものではなく、
サーバー側への影響が同じということじゃないでしょうか。

F5連打やボタン連打をされたとしても、サーバー側への副作用はないということです。
負荷はかかりますけど。

仮にこれが冪等ではないのであれば、冪等メソッドとして定義されているGETやDELETEも
冪等ではないということになります。

1回目にGETできたNAMEが「Foo」だったものが、2回目には「Bar」になっているかもしれませんし、
3回目には404かもしれません。
1回目でDELETEに成功すると、2回目のDELETEは404ですよね。

ただ、いずれの場合も何度実行されようが勝手にデータが書き換わったりはないので
冪等なんだと思います。
だから冒頭で書いた、オートインクリメントや更新日時の自動更新が発生してしまうと
送信した情報以外の情報も変わってしまってしまうので冪等ではないと思います。

投稿2018/05/23 02:45

編集2018/05/23 03:51
root_jp

総合スコア4666

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問