RailsにおけるRESTfulなURL設計勉強会 http://d.hatena.ne.jp/tkawa/20120726/p2

1. リソースモデリング
パターンの提案
@tkawa
2012.7.23 RailsにおけるRESTfulなURL設計勉強会
Sendagaya.rb #12

2. @tkawa
川村 徹
RESTとかRailsとか
書いてるブログ
http://d.hatena.ne.jp/tkawa/
うつの予防と回復
Web認知行動療法
U2plus http://u2plus.jp/

3. URL設計（リソース設計）
いろんな選択肢がある
• 例えば、URLの階層構造について、どれを選択す
る？
• /users , /user/{id}
• /users/user/{id}
• /users/{id}
• /users/user-{id}
• さらに、HTTPメソッドとの対応はどうする？
くわしくは http://d.hatena.ne.jp/tkawa/20120103/p1

4. Railsだと
Hoge::Application.routes.draw do
resources :users
end
• URLの構造も、HTTPメソッドとの対応もこ
れだけで決まる
• リソース設計の「パターン」を提供している
• ベストプラクティス

5. 「リソースモデリングパターン」
• どのパターンかを判断するだけで、既存の
Good Practiceが適用できる
• もっとあるはず！
• 名前をつけて呼べるようにしたい
• （できれば）Railsで簡単に書けるようにし
たい

6. まず、リソースを
分類してみた

7. リソース大分類
• コレクションリソース
• メンバーリソース
• 単数(Singular, Singleton)リソース
• 補助リソース
• アルゴリズムリソース
• 静的リソース
• ルートリソース
• その他…

8. コレクションリソース
メンバーリソース
/{name} /{name}/{id}
• 同じ種類のデータのまとまり
→コレクションリソース
その中の個別のデータ
→メンバーリソース
• コレクション名に“/”でIDをつなげることで
階層構造とする

9. Collection & Member
Resource パターン
• Railsの “resources”
• 2種類のリソースをまとめて、使用する
メソッドを限定
• コレクションリソースがFactoryとなる
GET POST PUT DELETE
/{name} index create - -
/{name}/{id} show - update destroy

10. 単数(Singular, Singleton)
リソース
/{name}
• ただ1つしかないリソース
• あるリソースに対して1つしかない
• セッションに対して1つしかない
• /users/123/profile

11. Singular(Singleton)
Resource パターン
• Railsの “resource”
GET POST PUT DELETE
/{name} show create update destroy

12. 補助リソース
/{name}/new
/{name}/{id}/preview
• 主にHTMLのUIのために必要となる、データ
の中身には関係のないリソース
• GETのみ
（命名規則を考え直すべきでは？ _new とか）

13. アルゴリズムリソース
/search?q={query}
/conversion?from=USD&to=JPY&amount=100
• クエリパラメータによって、何らかのア
ルゴリズムを実行した結果のリソース
• 基本的にGETのみ

14. 静的リソース
• 画像とかJavaScriptとかCSSとか
• Railsや、Webアプリケーションフレーム
ワーク特有の分類かもしれない
• GETのみ

15. ルートリソース
/
• 他のリソースへのナビゲーション的役割
（GETのみ）
• もしくは、サービスの主となるリソース
（コレクションリソースが多い）の別名

16. もう少し具体的な
パターンを探してみた

17. Filtered Collection
パターン
/users?role=admin
• コレクションリソース
＋アルゴリズムリソース
• コレクションリソースから、クエリパラメー
タの値を条件として絞り込む
• meta_search (gem)などが実装

18. Filtered Collection
パターン
/users?page=2
/users?since_id=123
• ページネーション
• kaminari (gem)などが実装

19. Filtered Subresource
パターン
/users/admin
• 汎用的なら、子リソースとしても表現できる
• コレクションリソースの一種
• IDと衝突注意
（実はこれをすんなり resources で書く手段がな
いが、GETのみなのでいいのかも）

20. Multi-member
Resource パターン
/users/123,124
/users/123-133
• メンバーリソースの派生形
• 複数のメンバーリソースを一度に取
得、更新、削除するために提供

21. Partial Resource
パターン
/users/123/name,email
or /users/123?fields=name,email
• リソースの部分取得、部分更新のため
に一部の属性（フィールド）だけを提
供する

22. Transaction Resource
パターン
POST /transactions
PUT /transactions/123
PUT /transactions/123/committed
• 主にCollection & Member Resource パ
ターンを用いたトランザクションの実装
• ウィザードなどにも適用可能

23. Session Resource
パターン
ログイン POST /session
ログアウト DELETE /session
• 認証のセッション自体をリソースととらえ
る（モデルではないリソースの典型例）
• Railsの認証gemではすでに一般的
(Deviseや Sorcery, OmniAuthのドキュメント)

24. Private Resource
(Namespace) パターン
/my/{resource}
• Singular Resource パターンの特別な場合
• 「自分自身」を指す特別なリソース
• 人によって違うリソースを指すことを
明示するため、名前空間を分ける

25. 意見ください
• ほんとうに役立つか
• これはパターンと言えるのか
• だいぶ粒度がバラバラ
• 名前の付け方（パターンは名前重要）
• まとめてどこかに書きたい！ 本？

26. • Collection & Member Resource パターン
• Singular(Singleton) Resource パターン
• Filtered Collection パターン
• Filtered Subresource パターン
• Multi-member Resource パターン
• Partial Resource パターン
• Transaction Resource パターン
• Session Resource パターン
• Private Resource (Namespace) パターン