Skip to content

Instantly share code, notes, and snippets.

@tkawa

tkawa/restful-towa-12.md

Created December 8, 2015 09:03
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tkawa/c33b7c265afdd5c3c827 to your computer and use it in GitHub Desktop.
Save tkawa/c33b7c265afdd5c3c827 to your computer and use it in GitHub Desktop.
Download ZIP
RESTful#とは勉強会12
Raw
restful-towa-12.md

RESTful#とは勉強会12 2015.12.08

質問はTwitterへ #RESTudy をつけてどうぞ。

「Webを支える技術」第10章 HTML

10.6 リンク (p.168)

第11章〜第13章

現在ほとんど使われていない記述があるので、飛ばしてもらってかまいません。

第11章 microformats はほとんど使われていません。現在 microformats の代わりになるものが Microdata や RDFa Lite です。

第12章 Atom もあまり使われていませんが、RSSも含む「フィード」という枠組みでは少し使われています。（12.5節「Atomの拡張」のOpenSearch以外はほとんど使われていません）

第13章 Atom Publishing Protocol もほとんど使われていません。

復習「RESTful Web アプリの設計レビューの話」

http://www.slideshare.net/t_wada/restful-web-design-review

スライドを読んで、感じたこと、疑問点などをグループで話し合いましょう。 スライド中の用語に関して理解が不安なときは「Webを支える技術」のページを振り返ってみましょう。

前回のおさらい＆ポイント解説

p.8 RESTfulアプリ設計のステップ

この後のスライドでそれぞれ解説してあるので、ここではすべて理解できなくてかまいません。また、この9ステップは手順の一例なので、他の手順もあり得ます。

ポイント

  1. 対象となるデータを認識する
  2. 対象となるデータをリソースに分ける

とありますが、対象となるデータとは何でしょうか？ どこにあるでしょうか？ →典型的なWebアプリであれば、データはRDBにあります。つまり、先にRDBのテーブル設計が必要になります。テーブルとカラムが重要になってきます。

実はこの 1, 2 は難しい部分です。

しかし、リソース指向アーキテクチャの設計アプローチには罠が潜んでいます。1 番めと 2 番めのステップ、つまり「Web サービスで提供するデータを特定」し、「データをリソースに分ける」方法がわからないのです。

— 「Webを支える技術」p.296 より

「Webを支える技術」では、この方法について3種類の候補を説明しています。

  • 関係モデルの ER 図からの導出
  • オブジェクト指向モデルのクラス図からの導出
  • 情報アーキテクチャからの導出

個人的には「情報アーキテクチャからの導出」がよい方法なのではと思っています。さらに単純に言うと、Webアプリで提供する画面と画面遷移を先に描き、各画面をリソースに当てはめるという方法です。詳細は各自で読んでみてください。（読書会でもいつか到達する…はず）

リソースへの分け方については後のスライドでも少し触れます。

  1. リソースにURLで名前を付ける
  2. リソースに対して統一インターフェイスのサブセットを提供する(GET/POST/PUT/DELETE をマッピング)
  3. クライアント

「名前を付ける」「GET/POST/PUT/DELETEをマッピング」「表現を設計する」がこのスライド「設計レビュー」で詳しく見ていく重要なポイントです。

p.9 設計レビューで見るポイント

  • URL 設計 (動詞、構造、クエリ)
    • CRUD の重力に引かれていないか
  • HTTP メソッドの選択
  • ステータスコードの選択
  • 表現の設計
    • 情報量に過不足は無いか
    • 接続性を満たしているか

p.12 URL が無理な構造になっていないか

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 でもいいのでは？

p.13 URL が無理な構造になっていないか

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 より

p.14 URL の意味と意思

「サーバ上の意味」「クライアントの意思」の区別はなかなか難しいので、感覚的にとらえましょう。

議論

DOM Scripting の原則に従う

  • Progressive Enhancement
  • Graceful Degradation
  • Unobtrusive JavaScript

JavaScriptがないと全く使えないようにするのはなるべくやめよう、シングルページアプリケーションは本当に必要かをよく考える。 ということだったんですが、最近はまた揺り戻してすべてJavaScriptにする傾向があるようです。

2012年の初回発表時に出た議論メモ http://qiita.com/tkawa/items/bedc9dbcf9547d0df313

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