ソフトウェア開発においては、RESTの概念が重要
RESTfulとは
あらかじめ決められたリソースを定義し、それに沿ってアクションとhttpメソッドを関連づけるという考え方。統一された書き方でコードを記述できる。
- URLを先に考えるのであって、ルーティングを先に考えるのでは無い。
→URLが頭の中で先に決まってて、それをもとにルートを書いてあげるって感じ。
→URL(=リソースを表している)は何を表示させるかを表しており、HTTPメソッドで何をしたいのかを決める。
リソースとは
「Web上に存在する、名前を持ったありとあらゆる情報のこと」(webを支える技術より)
一つ一つのリソースはURLによって一意の名前が付けられる(users/1
みたいな)
RESTfulに考えるとは
- ルーティングの定義を先に考えるのではなく、どういうリソースを表示させたいかを考える
- URLパターン(ブラウザに表示されるURL)を考える
- ルーティングを定義する。
→URLとは、「リソースの目印」みたいな役割なので、URLからぱっと何をするのかを推測できないといけない。
URLは親子関係を保つべき。
お気に入りした掲示板一覧はboards/bookmarks
みたいになるのが綺麗。(ただ、これは人によって意見が分かれるらしい)
つまり、7つのアクションをもとに作っていく原則があり、URLパターンを変えた方がいいとかの時は新しいアクションを作ったげる、てのが良さそう.
なぜ7つのアクション以外を定義するのか
例えば、掲示板削除のconfirmページ(確認ページ)を表示させたい場合に、わざわざconfirmコントローラを作るのはコストが高い。
→それなら、collectionルーティング で、boards#confirmアクションを増やしてあげればいいって感じ。
→ただ、用件が変わった時に修正するのが面倒というデメリットはある。
「リソース→URL→ルーティング」のRestfulな実装手順
要件:ブックマークした掲示板の一覧ページ(これがリソース)を表示させたい
例えばこんなルーティングを実装してみたとする。
これだと、 bookmarks/index.html.erb
はブックマークのページを表示させるみたいに見える。
resources :bookmarks, only: %i[index] → bookmarks GET /bookmarks(.:format) bookmarks#index
今回取得したいリソースは 「ブックマークした掲示板一覧」だから、boards/bookmarks
というURLの方が自然。
→「そのようなURLヘルパーを作るには?」と、ここでやっとルーティングの定義を考える。
resources :boards do collection do get :bookmarks end end bookmarks_boards GET /boards/bookmarks(.:format) boards#bookmarks
補足(memo)
boardsコントローラにbookmarksアクションを作る意味
bookmarks/*
以下のhtmlファイルは、ブックマークボタンの表示を切り替えるためのファイルとか、ajax送信行うためのjsファイルだけに纏められている。- ブックマークした掲示板の表示とか、掲示板関連は
boards/*
以下のhtmlファイルに纏められた。 - それにURLも、URLヘルパーも直感的に分かりやすくなる。
あと、どんなリソースを表したいのか考えれば簡単。
ブックマークした掲示板一覧を表示させたいなら、URLにboards
とbookmarks
ある方がどんなリソースを表しているのか直感的に分かりやすい。
memberとcollectionについて
用途
- resourcesでroutingを設定しているとき、resourcesでは自動で生成されないactionへのroutingを設定するときに使用。
- 生成するroutingに、:idが付くか付かないか。
違い
- member…コレクションの各メンバーに対してアクションを追加します。idを伴う時に使う。
- collection…コレクションそのものに対してアクションを追加します。idを伴わない時に使う。
resources :boards do resources :comments, only: %i[create], shallow: true collection do get :bookmarks end end
GET /boards/bookmarks(.:format) boards#bookmarks