Railsメモ - resourcesのオプション
はじめに
本記事では「パーフェクト Ruby on Rails」で学んだ内容と別途気になって調べた内容や知識も含めアウトプットしています。
書籍に記載されている内容を順序立ててまとめるというよりは、整理しておきたい周辺の知識と深ぼった内容を雑多に書いています。
resourcesのネスト
通常のresources
usersとplansをresourcesで定義します。
# routes.rb Rails.application.routes.draw do root "dashboard#index" namespace :api do namespace :v1 do 略 resources :users, only: [:index, :create, :update, :destroy] resources :plans, only: [:index, :create, :update, :destroy] end end end
上記のようにconfig/routes.rbを定義すると以下のルーティングになります。
# 実行
docker-compose run --rm backend rails routes
# 結果
api_v1_users GET /api/v1/users(.:format) api/v1/users#index
POST /api/v1/users(.:format) api/v1/users#create
api_v1_user PATCH /api/v1/users/:id(.:format) api/v1/users#update
PUT /api/v1/users/:id(.:format) api/v1/users#update
DELETE /api/v1/users/:id(.:format) api/v1/users#destroy
api_v1_plans GET /api/v1/plans(.:format) api/v1/plans#index
POST /api/v1/plans(.:format) api/v1/plans#create
api_v1_plan PATCH /api/v1/plans/:id(.:format) api/v1/plans#update
PUT /api/v1/plans/:id(.:format) api/v1/plans#update
DELETE /api/v1/plans/:id(.:format) api/v1/plans#destroy
resourcesをネストする
先程のroutes.rbではusersとplansをそれぞれresourceを用いて定義していました。
次に例として、定義したusersの中にplansを入れるように修正すると以下のようになります。
# routes.rb resources :users, only: [:index, :create, :update, :destroy] do resources :plans, only: [:index, :create, :update, :destroy] end
上記のようにするとルーティングが修正され、以下のようになりました。
# 実行 docker-compose run --rm backend rails routes # 結果 api_v1_user_plans GET /api/v1/users/:user_id/plans(.:format) api/v1/plans#index POST /api/v1/users/:user_id/plans(.:format) api/v1/plans#create api_v1_user_plan PATCH /api/v1/users/:user_id/plans/:id(.:format) api/v1/plans#update PUT /api/v1/users/:user_id/plans/:id(.:format) api/v1/plans#update DELETE /api/v1/users/:user_id/plans/:id(.:format) api/v1/plans#destroy api_v1_users GET /api/v1/users(.:format) api/v1/users#index POST /api/v1/users(.:format) api/v1/users#create api_v1_user PATCH /api/v1/users/:id(.:format) api/v1/users#update PUT /api/v1/users/:id(.:format) api/v1/users#update DELETE /api/v1/users/:id(.:format) api/v1/users#destroy
resourcesをネストすることによって、親子関係にあるモデルを表現することができます。
ネストしたリソースは、親のIDを含めることができます。例えば、先程の例でusersにplansをネストすると、以下のようなパスになります。
/users/:user_id/plans
resourcesをネストする - メリット
- 親リソースと子リソースの関係性を表現でき、RESTfulなURL設計が実現できます。
- コントローラでリソースを取得する際に親リソースの情報も含まれるため、paramsの活用の幅が増えます。
resourcesをネストする - デメリット
/api/v1/users/:user_id/plans/:id(.:format)などのようにURLが長くなるため、可読性が下がります。
member
特定のIDを持つリソースを対象としたアクションに対してルートを定義します。
例えば、あるプランを表示する際に必要なIDがある場合、そのIDを含んだルートを定義することができます。
# routes.rb resources :plans, only: [:index, :create, :update, :destroy] do member do get :detail end end
上記の例では、以下のルートが生成されます。
# 実行 docker-compose run --rm backend rails routes # 結果 (略) detail_api_v1_plan GET /api/v1/plans/:id/detail(.:format) api/v1/plans#detail
collection
リソース全体に対してアクションを実行する場合に使用します。
# routes.rb resources :plans, only: [:index, :create, :update, :destroy] do collection do get :search end end
上記の例では、以下のルートが生成されます。
# 実行 docker-compose run --rm backend rails routes # 結果 (略) search_api_v1_plans GET /api/v1/plans/search(.:format) api/v1/plans#search
使い分け - collectionとmember
memberは、対象となるリソースが特定のIDを持っている場合、特定のリソースを操作する際などに使用されます。
一方、collectionは、対象となるリソースが一意のIDを持たない場合、リソース全体を操作する際などに使用されます。
続く…
コメント
本記事の内容は以上になります！
書籍の続きのアウトプットも随時更新したいと思います。
プログラミングスクールのご紹介 (卒業生より)**
お世話になったプログラミングスクールであるRUNTEQです♪
こちらのリンクを経由すると１万円引きになります。
RUNTEQを通じて開発学習の末、受託開発企業をご紹介いただき、現在も双方とご縁があります。
もし、興味がありましたらお気軽にコメントか、TwitterのDMでお声掛けください。
