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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://d.hatena.ne.jp	791
https://si0.twimg.com	14
https://twimg0-a.akamaihd.net	7
http://us-w1.rockmelt.com	5
https://twitter.com	5
http://b.hatena.ne.jp	1
http://tweetedtimes.com	1
http://seekr-artemis.heroku.com	1

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

by Toru Kawamura on Jul 23, 2012

Accessibility

Categories

Upload Details

Usage Rights

8 Embeds 825

Statistics