RESTful Web APIs 読書会( 第三回 )に参加してきた

久々の更新。しばらくRailsで趣味の開発に没頭しておりました。

というわけで 今回はRESTful Web APIs読書会(第三回)の参加報告を。

今回は主に「リソースの定義」と「HTTPリクエストの種類」と「安全性・べき等性」のお話。

・リソースの定義

リソースというと結構個人的に定義が曖昧で、データベースのデータとかがメインになるのかなと思っていたけど、どうやらRESTにおいて URIで表現されるものは全てリソースになるらしい。

そしてリソースの状態は以下の二つによって表現されうるらしい。

( 2013年12月1日改正、コメントより「リソースが(同じ状態で)複数の表現を持つ場合に、クライアントは望む表現をどのように指定するか、の選択肢である」といただきました。必ずしも二つではないということですね )

1. Content negotiation( 「内容ネゴシエーション」とも。HTTPリクエストとレスポンスから成るクライアントサーバ間のやり取り? )
2. URI( Railsで言うと new とか edit とかでURIが分かれてるイメージ? )

・HTTPリクエストの種類

・GET

最も一般的なリクエスト。クライアントがリソースの何らかの表現を得るためのもの。

・POST

クライアントが新たにリソースを作成するためのもの。

実際、HTMLでは「GET」「POST」しかサポートしていなかったのもあって、これまでの世の中の一般的なWebサービスはPUTやらDELETEやら何でもかんでもPOSTでやってた風潮があった( 因みに そういう場合は「overloaded POST」というらしい )けど、著者は非推奨している。

・PUT

主に既存のリソースの更新に使用される。

リクエスト対象は PUT /some_resource/hogehoge みたいな感じに成る。

PUTでPOSTの役割(新しいリソースを作成する)を果たすこともできる。その場合、クライアントが リクエストを投げるURIをあらかじめ知っている必要がある。

実例を挙げるとするならばWikiみたいな感じ。「hogehoge」についての記事を書こうと ユーザがリクエストを投げた際、既にリソースがあれば更新、リソースが無ければ新たにリソースをつくる みたいなイメージ。

・DELETE

リソースの削除。

・PATCH

PUTに似ているが、diff(差分)を取って 変更のあった部分のみ更新。

その他 LINK / UNLINKHEADOPTIONS 等々。重要なのは上記に挙げた5つ。

結局どのメソッドを使えば良いかは それぞれのAPI提供者を取り巻くコミュニティに依存すると言ってよい。HTMLに準拠するなら「GET/POST」しか使えないだろうし、Railsなら「GET/POST/PUT/DELETE」だろうし、ファイルシステムのGUIとか関わってくるなら上記に挙げた例意外にWebDAVとか入ってくるだろうし。

・安全性、べき等性

・安全性

リソースが増えたり書き変わったり消えたり、リソースそのものに影響があるかどうか。

RESTの設計原則に基づく場合、GET は 安全である( あるURIにGETでアクセスしたらいきなりデータ消えちゃった!みたいなことが無い…とかそんなイメージ )。

・べき等性

あるリクエストを送った時に、常に同じレスポンスを保証するかどうか。

2013年12月1日改正、上記についてコメントより「 1回送っても複数回送ってもリソースの状態が同じであること」といただきました。レスポンスが常に同じではなくても良いみたいです )

GET, PUT, DELETE はべき等。

因みに、べき等性について は以下に示すように数学の計算から来ている概念だとか。

・DELETEの場合… ある数字に 0 をかけた場合、その後何回 0 をかけても 0 から変わらないというのと同じイメージで、あるリソースに対して一度DELETEリクエスト送ったらその後 レスポンスは 変わらない。

・GETの場合… ある数字に 何回 1をかけても最初の数値から変わらないというのと同じイメージで、あるリソースに対して何回GETリクエスト送っても返ってくるレスポンスは変わらない。

・気になった点など

Q.「複数条件で検索結果を絞る」みたいな実装をする場合に POSTを使ったりするけど、これってどうなんだろう

A. 上記で説明したoverloaded POSTにあたる。検索条件が長過ぎてGETじゃさばけない時にPOSTを使ったりとか。Googleの検索結果のURIみたいに一般的にはGETを使うらしい。

Q. 上記でGETを使う場合、RESTの特徴の一つである「シンプルなURI」の点でどうなんだろう

A. 「RESTful Web APIs」の著者が URIに関して 書籍ではあまり触れていない印象。URIに関してはそこまで重要視していない感じ? なお、「RESTful Web Services」にもURI設計についての記載があるらしいのでそちらを参照すると良いかも。

・頂いたもの

オライリーのステッカー。JSでよく見かけるサイが左下に。飛び上がるほど嬉しかったです。

1

DevOpsの小冊子。今読んでいるデザパタの本と並行して読ませていただきます。

devops

そしてRESTful Web APIs。ドキドキが止まらない。

restful

今回もとても勉強になりました。

RESTやHTTPというと結構つかみ所の無い印象だったけれど、最近ようやくフレームを理解し始めた感じです。

そう考えると勉強会って 分からない部分や気になっている部分を参加者主体で共有したり議論したりできるからすごく良い機会だなって思いました。

次回のRESTful Web APIs 読書会は 11/28(木) 19:30- 。今から楽しみです。

Written by Nisei Kimura ( 木村 仁星 )

- Sponsored Links -

<<

Top

>>