Collection & Member Resource パターン
/users /users/123
どのようなパターン?
コレクションリソースとメンバーリソースの2種類のリソースをひとまとめとして扱い、使用するメソッドを限定する。
コレクションリソースがFactoryの役割も果たす。
Railsのリソース設計では基本となるパターンであり、9割方これで済むといっても過言ではない。(なので用途を絞った派生パターンを考えていく必要がある:Transaction Resource パターンなど)
使用メソッドとの組み合わせ
Railsのアクション名を例に挙げる。
GET | POST | PUT | DELETE | |
---|---|---|---|---|
/{name} |
index | create | - | - |
/{name}/{id} |
show | - | update | destroy |
すべてを使うことはまれなため、8種類中5種類に使用を限定しているのがポイント。
リソースの分類からみる
/{name} (コレクションリソース) /{name}/{id} (メンバーリソース)
同じ種類のデータのまとまりを「コレクションリソース」、その中の個別のデータを「メンバーリソース」と呼ぶ。
コレクション名に“/
”でIDをつなげることで階層構造とする点が特徴。
例
GET /users
ユーザ全体を取得。
POST /users
新しいユーザのリソースを作成(Factory)。
主なステータス:201 Created, 302 Found, 303 See Other
GET /users/123
ID=123のユーザのリソースを取得。
PUT /users/123
ID=123のユーザのリソースを変更。
DELETE /users/123
ID=123のユーザのリソースを削除。
補助リソース
/{name}/new /{name}/{id}/preview
主にHTMLのUIのために必要となる、データの中身には関係のないリソース。
Railsでresources
を使用すると、上記の5種類のアクションに加えて、new
, edit
の2つのアクションが作られる。これが補助リソースである。
あくまでフォームを表示するだけのリソースであるため、実装によっては必要ない。
メンバーリソースのIDと衝突しないように注意。_new
のようにアンダースコアをつけるなどの命名規則を導入すれば回避できる。
Rails routes.rb の書き方
# /users # /users/id の場合 resources :users