質問はTwitterへ #RESTudy をつけてどうぞ。
10.6 リンク (p.168)
現在ほとんど使われていない記述があるので、飛ばしてもらってかまいません。
第11章 microformats はほとんど使われていません。現在 microformats の代わりになるものが Microdata や RDFa Lite です。
第12章 Atom もあまり使われていませんが、RSSも含む「フィード」という枠組みでは少し使われています。（12.5節「Atomの拡張」のOpenSearch以外はほとんど使われていません）
第13章 Atom Publishing Protocol もほとんど使われていません。
http://www.slideshare.net/t_wada/restful-web-design-review
スライドを読んで、感じたこと、疑問点などをグループで話し合いましょう。 スライド中の用語に関して理解が不安なときは「Webを支える技術」のページを振り返ってみましょう。
この後のスライドでそれぞれ解説してあるので、ここではすべて理解できなくてかまいません。また、この9ステップは手順の一例なので、他の手順もあり得ます。
ポイント
- 対象となるデータを認識する
- 対象となるデータをリソースに分ける
とありますが、対象となるデータとは何でしょうか？ どこにあるでしょうか？ →典型的なWebアプリであれば、データはRDBにあります。つまり、先にRDBのテーブル設計が必要になります。テーブルとカラムが重要になってきます。
実はこの 1, 2 は難しい部分です。
しかし、リソース指向アーキテクチャの設計アプローチには罠が潜んでいます。1 番めと 2 番めのステップ、つまり「Web サービスで提供するデータを特定」し、「データをリソースに分ける」方法がわからないのです。
— 「Webを支える技術」p.296 より
「Webを支える技術」では、この方法について3種類の候補を説明しています。
- 関係モデルの ER 図からの導出
- オブジェクト指向モデルのクラス図からの導出
- 情報アーキテクチャからの導出
個人的には「情報アーキテクチャからの導出」がよい方法なのではと思っています。さらに単純に言うと、Webアプリで提供する画面と画面遷移を先に描き、各画面をリソースに当てはめるという方法です。詳細は各自で読んでみてください。（読書会でもいつか到達する…はず）
リソースへの分け方については後のスライドでも少し触れます。
- リソースにURLで名前を付ける
- リソースに対して統一インターフェイスのサブセットを提供する(GET/POST/PUT/DELETE をマッピング)
- クライアント
「名前を付ける」「GET/POST/PUT/DELETEをマッピング」「表現を設計する」がこのスライド「設計レビュー」で詳しく見ていく重要なポイントです。
- URL 設計 (動詞、構造、クエリ)
- CRUD の重力に引かれていないか
- HTTP メソッドの選択
- ステータスコードの選択
- 表現の設計
- 情報量に過不足は無いか
- 接続性を満たしているか
URLが右にいくに従って自然な階層構造/サブセットになっているか
URLは「/」で区切られた階層構造。ファイル・ディレクトリ構造をイメージしましょう。URLの末尾を削っていってもアクセスできるかどうかが目安です。
http://www.tumblr.com/show/everything/by/me →
http://www.tumblr.com/show/everything/by や http://www.tumblr.com/show/everything は何？（階層にする意味がない）
http://www.tumblr.com/everything-by-me
http://www.tumblr.com/everything?by=me でもいいのでは？
URL 設計のほとんどの時間は「名前を探す」ことに費やされる
とくにシソーラス（類語辞典）は必須。類語・同義語を調べて一番マッチするものを選びましょう。
http://www.thesaurus.com/ など
リソースとリソースの関係を表す第三のリソースを探す
これはRDBテーブル設計で交差テーブルを見つけるときにも重要です。
- subscription (person <=> magazine)
- belonging, membership (person <=> group)
- friendship, relationship (person <=> user)
- tagging (thing <=> tag)
- categorization (thing <=> category)
- enrollment (person <=> course)
- possession (person <=> thing)
- assignment (person <=> task)
- offer (school <=> course)
- employment (employee <=> company)
- participation (person <=> event)
- like, favorite
リソースは DB レコードだけでは無い
↓
HTTP メソッドでは実現できない機能があると感じたら、それが独立した別リソースで代替できないかを考える。検索機能を実現する SEARCH メソッドを HTTP に追加するのではなく、「検索結果リソース」を GET する、と考えることが重要である
— 「Webを支える技術」p.295 より
「サーバ上の意味」「クライアントの意思」の区別はなかなか難しいので、感覚的にとらえましょう。
DOM Scripting の原則に従う
- Progressive Enhancement
- Graceful Degradation
- Unobtrusive JavaScript
JavaScriptがないと全く使えないようにするのはなるべくやめよう、シングルページアプリケーションは本当に必要かをよく考える。 ということだったんですが、最近はまた揺り戻してすべてJavaScriptにする傾向があるようです。
2012年の初回発表時に出た議論メモ http://qiita.com/tkawa/items/bedc9dbcf9547d0df313