リソースモデリング
    パターンの提案
              @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設計(リソース設計)
        いろんな選択肢がある
•   例えば、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/profile
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,email

or /users/123?fields=name,email

 • リソースの部分取得、部分更新のため
   に一部の属性(フィールド)だけを提
   供する
Transaction Resource
       パターン
POST /transactions
PUT /transactions/123
PUT /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) パターン

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

  • 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.
  • 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) パターン