今日は千駄ヶ谷.rbに初参加してきました。
tkawaさんのRESTfulなURLについての発表が気になっていたので、
参加申し込みをしていたら、t_wadaさんとmoroさんが発表者になっていて、
15人の勉強会でやるには、非常に贅沢な内容になってました。
余りに得る物が多かったので、ざっくりとでもすぐにまとめておこうと思いました。
URLを考える上で大事な点(自分の考えも含めて)
- URLが示すリソースは、データとして欲しい「もの」なので、名詞で示されるのが自然
- それを表現するためには、/addなどの形ではなく、関連を示すような論理的なオブジェクトを作成すると考え、論理オブジェクトを示すURLにPOSTする、等の感覚が必要になる。
- アプリケーションの遷移状況を示すような、トランザクションもリソースとなりえる。バッチ処理の開始をPOSTで行ない、子リソースをGETすることで進捗状況の断片を取り出す等
- /という区切りで表現されるべき従属関係にあるかどうかを考える。何でもパス構造に含めるのが自然とは限らない。
- 例えば、並列な関係にあるコピー元とコピー先の関係等は、パス構造に馴染まない。
- クライアントがURLを知り過ぎると変更の柔軟性に欠ける。
- URLが指し示す基本的な意味と、クライアントが見せ方として要求していることの違いを意識する。
- ステータスコードはちゃんと考える。例外設計とも関係。
- URLの示すリソースの粒度とRDBMSのデータ粒度は違う。マスタ管理をするようなインターフェースだと1:1になることも多い。
- 正規化されたRDBMSのデータ構造にこだわる必要は無い。アプリケーション上にマッピングされたオブジェクトはもっと表現力が高い。
- 非同期処理とRESTのやり過ぎはN+1問題で接続数が膨れあがる可能性がある。
RailsにおけるURL設計の注意点
- 規約によって名前の影響する範囲が広いので、修正漏れに注意
- ActiveRecordが強力かつテーブルとの関連が強いので、テーブルとURLが示すリソースを1:1に固定化しがち。適切なモデルオブジェクトは必ずしもActiveRecordと一致しない。
- routes.rbが余りに大きくなる場合は、モジュールとして分離することも考慮。
- routes.rbもrubyであることには変わりないので、モジュールのincludeなどを駆使すれば、自在に分割できると思う。試してないけど。
- controllerにif文は、表現上の必然性が無い場合を除いて、良くない構造。
- DBによって自動採番された連番がURLに見えるのはセキュリティとキーとしての永続性を考えると、それなりに思い切った設計になっている。
- データ設計をする時には、人が意味を認識できる自然キーによって一意に特定できるようにしておく。
- RailsのURLとして解釈できるIDは別に数字に限らない。が、パラメーターのパース周りでハマりポイントもあるらしい。
- 関連テーブル(has_many :through)をリソースとして活用する。
- 関連テーブルの命名は、上手く概念を表現する英単語が無ければ、動名詞,---ship,---ing,等を活用する。
javascriptとの関係
URLと対応するリソースの表現スタイルをまとめたパターン
tkawaさんが示してくれたURLのパターンは、名前付けて体系的に分類すれば、
色んな人が使えるプラクティスになりそう。
URLが表現できる定型的なパターンの一覧があれば、データ構造とモデリングの指針になるんじゃないか。
詳しくは http://www.slideshare.net/tkawa1/resource-modeling-pattern
t_wadaさんの発表資料 (追記: 2012/7/24)
RESTful Web Design Review
http://www.slideshare.net/t_wada/restful-web-design-review
まとめ
URLはWebシステム開発においては、ユーザーに見えるインターフェースの設計にそのまま直結する部分で、
データ定義と、ドメインモデルに相当するリソースをどうやって扱うか、
それがモロに表われてくる箇所だと思います。
URLをしっかり考えられる、ということはその裏にあるドメインモデルを描き出せていないといけない。
特に、ここしばらくDDD本を少しづつ読んでいるので、自分の中でこのあたりとの繋がりを強く感じました。
その点で、今回の勉強会はアプリケーション設計の根幹に関わる議論が出来たように思えます。
本当、めちゃめちゃ勉強になりました。
ってか、どっかで再演希望とか出るんじゃないか、これw
(思い出したら、また追記するかも。)
