Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?

RESTful#とは勉強会4 2015.02.10

第7章 HTTPメソッド

重要な用語

考えてみよう

POSTとPUTの使い分け (p.95)

ただし PUT の場合、リソースの上書きを避けるためにクライアントで事前に URI の存在をチェックしなければならないかもしれません。

どうすればチェックできるでしょうか? チェックしなくてもすむ方法はあるでしょうか?

べき等性と安全性 (p.101)

「安全」と「べき等」の概念は理解できましたか? とくに「べき等」を噛み砕いて言うと? 本文の例のほかに「べき等」な例を挙げてみましょう。

よく使うRubyのメソッドがべき等かどうか考えてみましょう。

べき等だと何がメリットなのでしょうか?

解説

CRUD (p.89)

http://ja.wikipedia.org/wiki/CRUD

GET / POST / PUT / DELETE

POST

POSTには「何でもありのPOST」の意味もある。 これを「オーバーロードPOST」と呼ぶこともあります。

PUT

PUTでの更新は「全部置き換える」のが原則です。 部分的な更新など、PUTで表せない更新はPOST(かPATCH)になります。

PATCH

本書には取り上げられていませんが、PATCHも最近使われています。

PATCHはリソースの部分的な変更のためのメソッドです。ただし、HTTP仕様の標準ではなく、別の標準になっています。(RFC5789)

"RESTful Web APIs" p.38より引用:

完全な表現をPUTする代わりに、特別な 「差分」表現を作成し、PATCHリクエストのペイロードとして、それをサーバに送信することができます。

PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: "abc123"

[
  { "op": "test", "path": "/a/b/c", "value": "foo" },
  { "op": "remove", "path": "/a/b/c" },
  { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
  { "op": "replace", "path": "/a/b/c", "value": 42 },
  { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
  { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]

PATCHは、安全でもべき等でもありません。

POSTとPUTの使い分け (p.95)

リソースの上書きを避ける

ただし PUT の場合、リソースの上書きを避けるためにクライアントで事前に URI の存在をチェックしなければならないかもしれません。

GETもしくはHEADリクエストを送って 200 or 404 を確認することで存在はチェックできます。通常はこれで十分なことが多いですが、他にもPUTしようとする人がいる場合など、競合する可能性が高いときはさらに良い方法として「条件付きリクエスト」(楽観的ロック)が使えます。

例えば If-None-Match: * ヘッダをつけてPUTリクエストを送ると、「現在のリソースがない場合のみリソースを更新する」という意味になります。(https://tools.ietf.org/html/rfc7232#section-3.2)

楽観的ロックについて、詳しくは16章(p.290-)を参照。

べき等かどうかの違い

POSTとPUTの違いは「URIの決定権」と書かれていますが、べき等かどうかも大きな違いです。

更新系メソッド 安全 べき等
PUT ×
POST × ×
PATCH × ×

「ほかのメソッドでできることにPOSTを誤用」 べき等な処理にPOSTを使っていませんか?

べき等性と安全性 (p.101)

これは次回にしましょう。 みなさんおつかれさまでした!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment