RailsでのURL設計を考えてみる(5) Railsのリソースパターン

URL設計の前段階として、とても大切なのがリソース設計です。そのWebアプリ・Webサービスで何を提供するのかが決まる部分だからです。しかし、なかなかリソースという概念が定着していないようなので、Railsで採用されているパターン*1を例に挙げて紹介してみたいと思います。
今までのシリーズ記事と重なるところもありますが、まとめということで…。

リソースとは

簡単に言うと、「URLで示されるもの」です。URLというのが“Uniform Resource Locator”の略ですからね。

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

最初のものは、前回書いたブログ記事『RailsでのURL設計を考えてみる(4) スラッシュと「持っている」関係』というリソースです。
その次は、『tkawaが2011年8月19日に書いたブログ記事』というリソースです。実際には中身の記事は1つしかないのですが、もし複数の記事があれば列挙されることになります。
これに限らず、URLで示すことができる情報はすべてリソースです。URLはリソースにつけられた名前ともいえます*2。

Railsで用意されているパターン

すべてがリソースなのでいろいろな種類がありうるのですが、その中でも典型的なパターンがいくつか存在します。Railsでは、そのパターンに沿って設計すると簡単に書けるようになっています。

MemberリソースとCollectionリソース

Memberリソースは一番基本となるリソースです。1個のオブジェクトや、データベースの1レコードを指すというイメージです。
このようなURLがMemberリソースの例です。

http://d.hatena.ne.jp/tkawa/20110819/p1
http://baseball.example.jp/leagues/central
http://railsapp.example.com/users/12

Collectionリソースは、Memberリソースを種類ごとにまとめたもので、ちょうどディレクトリ（フォルダ）のようなイメージです。
例はこのようなURLです。

http://d.hatena.ne.jp/tkawa/20110819
http://baseball.example.jp/leagues
http://railsapp.example.com/users

見ると気づきますが、Memberリソースの末尾を削ったものになっています。言い換えると、Collectionリソースの後ろにスラッシュ区切りでIDをくっつけることで、MemberリソースのURLになります。

Member, CollectionリソースのURLの構造*3

/{collection_name}/{id}
/{collection_name}

Collectionリソースの名前(collection_name)は名詞の複数形が推奨されます。Memberリソースの名前(id)は、そのリソースをCollection内で一意に特定できる名前、もしくは番号です。

Singular（単数）リソース

Singularリソースは、Memberリソースと似ていますが、ただ1つしかないリソースです。これはグローバルに1つしかないという場合のほかにも、あるMemberリソースに1対1で結びついている場合、セッションなどの暗黙のパラメータに対して1つしかない場合も含まれます。
例はこのようなURLです。

http://b.hatena.ne.jp/tkawa/config
http://railsapp.example.com/users/12/profile
http://u2plus.jp/user

最後の例は、僕が制作に関わっているサービスのU2plusの例なのですが、“/user”で「現在ログインしているユーザ」というリソースを指すことにしています。これはセッションに対して1つしかないリソースになっています。
Singularリソースの名前は、名詞の単数形が推奨されます。

routes.rbの書き方

上記のパターンに従えば、routes.rbの書き方はとても簡単です。

Memberリソース、Collectionリソースの場合

resources :users

これで、“/users”というCollectionリソースと、“/users/{id}”というMemberリソースができます。

Singularリソースの場合

resource :user

これで、“/user”というSingularリソースができます。

組み合わせ

組み合わせるときも、このようにネストするだけです。

resources :users do
  resource :profile
end

これで、“/users”、“/users/{id}”に加えて、“/users/{id}/profile”というSingularリソースができます。

リソース設計の指針

Railsで採用されているリソースのパターンはかなり一般的で、多くの部分に適用できるので、リソース設計の指針になります。さらにRailsではそれに対応して自動的にURLやコントローラの設計も決まります。
もちろんもっと細かく設計したいこともあるでしょう。そのときはこれをベースにカスタマイズしていけばいいわけです。そのための方法も十分に用意されています。

また、Railsだけでなく、Sinatraなどのほかのフレームワークを使って設計するときも、このパターンをまず参考にしてみるのがいいと思います。

*1:各書籍を見ると「リソースモデル」という用語が主に使われているようですが、Railsでは「モデル」が紛らわしいので、ここではあえて「パターン」と呼ぶことにします

*2:ではURL=リソースなのかというと、同じリソースが複数のURLをもつこともあるので、厳密には違うのですが、ほぼ同じと思っても問題ないでしょう

*3:{ } は、URIテンプレートというURL中にパラメータを含むときの記法です