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のために必要となる、データの中身には関係のないリソース。

Railsresourcesを使用すると、上記の5種類のアクションに加えて、new, editの2つのアクションが作られる。これが補助リソースである。

あくまでフォームを表示するだけのリソースであるため、実装によっては必要ない。

メンバーリソースのIDと衝突しないように注意。_newのようにアンダースコアをつけるなどの命名規則を導入すれば回避できる。

Rails routes.rb の書き方

# /users
# /users/id の場合
resources :users