リソースモデリングパターンの提案

@tkawa

2012.7.23 RailsにおけるRESTfulなURL設計勉強会Sendagaya.rb #12

@tkawa川村 徹

RESTとかRailsとか書いてるブログ

http://d.hatena.ne.jp/tkawa/

うつの予防と回復Web認知行動療法

U2plus http://u2plus.jp/

• 例えば、URLの階層構造について、どれを選択する？

• /users , /user/{id}

• /users/user/{id}

• /users/{id}

• /users/user-{id}

• さらに、HTTPメソッドとの対応はどうする？

URL設計（リソース設計）いろんな選択肢がある

くわしくは http://d.hatena.ne.jp/tkawa/20120103/p1

• URLの構造も、HTTPメソッドとの対応もこれだけで決まる

• リソース設計の「パターン」を提供している• ベストプラクティス

RailsだとHoge::Application.routes.draw do  resources :usersend

「リソースモデリングパターン」

• どのパターンかを判断するだけで、既存のGood Practiceが適用できる

• もっとあるはず！

• 名前をつけて呼べるようにしたい

• （できれば）Railsで簡単に書けるようにしたい

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

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

コレクションリソースメンバーリソース

• 同じ種類のデータのまとまり→コレクションリソースその中の個別のデータ→メンバーリソース

• コレクション名に“/”でIDをつなげることで階層構造とする

/{name} /{name}/{id}

• Railsの “resources”

• 2種類のリソースをまとめて、使用するメソッドを限定

• コレクションリソースがFactoryとなる

GET POST PUT DELETE

/{name} index create - -

/{name}/{id} show - update destroy

Collection & Member Resource パターン

単数(Singular, Singleton)

リソース

• ただ1つしかないリソース

• あるリソースに対して1つしかない

• セッションに対して1つしかない

• /users/123/profile

/{name}

Singular(Singleton) Resource パターン

• Railsの “resource”

GET POST PUT DELETE

/{name} show create update destroy

補助リソース

• 主にHTMLのUIのために必要となる、データの中身には関係のないリソース

• GETのみ

（命名規則を考え直すべきでは？ _new とか）

/{name}/new

/{name}/{id}/preview

アルゴリズムリソース

• クエリパラメータによって、何らかのアルゴリズムを実行した結果のリソース

• 基本的にGETのみ

/search?q={query}

/conversion?from=USD&to=JPY&amount=100

静的リソース

• 画像とかJavaScriptとかCSSとか

• Railsや、Webアプリケーションフレームワーク特有の分類かもしれない

• GETのみ

ルートリソース

• 他のリソースへのナビゲーション的役割（GETのみ）

• もしくは、サービスの主となるリソース（コレクションリソースが多い）の別名

/

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

Filtered Collectionパターン

• コレクションリソース＋アルゴリズムリソース

• コレクションリソースから、クエリパラメータの値を条件として絞り込む

• meta_search (gem)などが実装

/users?role=admin

Filtered Collectionパターン

• ページネーション

• kaminari (gem)などが実装

/users?page=2

/users?since_id=123

Filtered Subresourceパターン

• 汎用的なら、子リソースとしても表現できる• コレクションリソースの一種• IDと衝突注意

（実はこれをすんなり resources で書く手段がないが、GETのみなのでいいのかも）

/users/admin

Multi-member Resource パターン

• メンバーリソースの派生形

• 複数のメンバーリソースを一度に取得、更新、削除するために提供

/users/123,124

/users/123-133

Partial Resourceパターン

• リソースの部分取得、部分更新のために一部の属性（フィールド）だけを提供する

/users/123/name,email

/users/123?fields=name,emailor

Transaction Resource パターン

• 主にCollection & Member Resource パターンを用いたトランザクションの実装

• ウィザードなどにも適用可能

POST /transactionsPUT /transactions/123PUT /transactions/123/committed

Session Resourceパターン

• 認証のセッション自体をリソースととらえる（モデルではないリソースの典型例）

• Railsの認証gemではすでに一般的(Deviseや Sorcery, OmniAuthのドキュメント)

POST /sessionDELETE /session

ログインログアウト

Private Resource (Namespace) パターン

• Singular Resource パターンの特別な場合

• 「自分自身」を指す特別なリソース

• 人によって違うリソースを指すことを明示するため、名前空間を分ける

/my/{resource}

意見ください• ほんとうに役立つか

• これはパターンと言えるのか

• だいぶ粒度がバラバラ

• 名前の付け方（パターンは名前重要）

• まとめてどこかに書きたい！ 本？

• Collection & Member Resource パターン

• Singular(Singleton) Resource パターン

• Filtered Collection パターン

• Filtered Subresource パターン

• Multi-member Resource パターン

• Partial Resource パターン

• Transaction Resource パターン

• Session Resource パターン

• Private Resource (Namespace) パターン