#ルーティングとは
前提知識として、**RailsアプリケーションのMVCモデル**について調べてみてください。リンクは一例です。
改めてルーティングとは、
Railsアプリケーションのコントローラへ指示を出すための道筋
と捉えて良いでしょう。
この記事で説明するなら、URLがルーティングにあたります。
Railsでは、ルーティングの指示に従いコントローラのアクションが実行されます。
root "tweets#index"
「root」という道筋でアプリケーションにたどり着いたなら
「tweetsコントローラーのindexアクションを動かしてね!」
#ルーティングを記述する
ルーティングを記述するファイル
Rails.application.routes.draw do
# この中にルーティングを記述します。
end
##基本の書き方
tweetsコントローラーを生成したとします。
Rails.application.routes.draw do
root "tweets#index"
get "tweets/new" => "tweets#new"
post "tweets" => "tweets#create"
end
解説
root:アクセスして一番最初のコントローラへの指示
rootは主にトップページなどに用いられます。
HTTPリクエスト | URL(パス) | コントローラ名#アクション名 |
---|---|---|
get | tweets/new | tweets#new |
post | tweets | tweets#create |
このように記述している場合
例えばアプリケーションのサーバーにアクセスした状態で、/tweets/newと続ければ、tweetsアクションのnewメソッドが実行されます。
[HTTPリクエスト]
(https://developer.mozilla.org/ja/docs/Web/HTTP/Methods):クライアントからのリクエスト種別
詳しくはリンクを参照してください。
基本の書き方では個別で一つ一つのアクションに対してルーティングを指定することができます。
しかし、これでは処理が増えてきた場合に全て記述するのは大変で、ミスも生まれやすくなります。
そこで、Railsではアプリケーションの基本アクションのルーティングをまとめて記述する方法があります。
##resources
Railsで基本となる7つのアクションへのルーティングを定義する際に用います。
次のようにまとめると理解しやすいでしょう
閲覧 | index | show |
---|---|---|
生成 | new | create |
更新 | edit | update |
削除 | delete | - |
###記述方法
Rails.application.routes.draw do
resources :コントローラー名
resources :コントローラー名, only: [:index, :show]
end
only:指定することで必要なルーティングのみに絞ることができます。
tweetsコントローラーがある場合で試してみます。
Rails.application.routes.draw do
resources :tweets
end
$ rake routes
Prefix Verb URI Pattern Controller#Action
tweets GET /tweets(.:format) tweets#index
POST /tweets(.:format) tweets#create
new_tweet GET /tweets/new(.:format) tweets#new
edit_tweet GET /tweets/:id/edit(.:format) tweets#edit
tweet GET /tweets/:id(.:format) tweets#show
PATCH /tweets/:id(.:format) tweets#update
PUT /tweets/:id(.:format) tweets#update
DELETE /tweets/:id(.:format) tweets#destroy
rake routes:アプリケーションに設定されているルーティングを調べることができます。
Verb、URI Pattern、Controller#Action
この3つが基本の書き方と同じ意味になります。
※(.:format)はここでは深掘りしません。
##resource
resourcesからsを取っただけです、ここには明確な違いがありますので注意してください。
以下が実際のコードです。
Rails.application.routes.draw do
resource :tweet
end
$ rake routes
Prefix Verb URI Pattern Controller#Action
new_tweet GET /tweet/new(.:format) tweets#new
edit_tweet GET /tweet/edit(.:format) tweets#edit
tweet GET /tweet(.:format) tweets#show
PATCH /tweet(.:format) tweets#update
PUT /tweet(.:format) tweets#update
DELETE /tweet(.:format) tweets#destroy
POST /tweet(.:format) tweets#create
違いは
・indexアクションが定義されないこと
・URI Patternにidを含まないこと
の2点です。
###メリット
idを参照せずとも単数の処理が確定しているものに利用します。
例えばユーザーのプロフィールなど
ですので、resource続くのは単数形にすべきでしょう。
記事では比較のためにtweetで記述しました。
##ルーティングをネストする
まずはコードを見てください。
resources :contents do
resources :comments
end
とてもシンプルですね、
commentsのルーティングをdo ~ endで囲んであります。
このように記述することで、どのcontentに対してのcommentであるかをルーティングで紐づけることができます。
ターミナルでルーティングを確かめてみましょう!
$ rake routes
//抜粋
content_comments POST /contents/:content_id/comments(.:format) comments#create
こんな表記があればネストできています。
コメントが、どのコンテンツに属しているのか関係を示したルーティングを設定しています。
###メリット
この時、:content_idと表記された値は**params[:content_id]**で取得することができます。
なんでidを取得する必要があるの??と疑問を感じた方は
データベース、モデルのアソシエーションなどを同時に学習するとより深い理解に繋がるかと思います。
参考
データベース→https://qiita.com/JunInaba1/items/15bdcbda8975555a461d
モデル:アソシエーション→https://qiita.com/To_BB/items/47d2c7b1bc3513025d7b
ネスト構造を複雑にすると複数のparamsをパスに持たせることも可能です。
色々試してみてください。
namespaceについても書きたかったのですが、情報量が多いので別の記事にしようと思います。
至らない点があればご指摘いただければと思います。
少しでも皆さんの役に立てば幸いです。