はじめに

Railsには、newで作った最初の状態から、様々なファイルが存在しています。

それらのファイルのすべてに意味がありますので、少しずつでも理解しておかなければ、思った通りのRailsアプリを使うことは難しいでしょう。

特に、configフォルダにあるファイルは重要で、中でも重要なのがroutes.rbファイルと言えます。

ここでは、そんなroutes.rbについて、詳しく解説していきます。

routes.rbを読めるようになると、Railsアプリの動きや画面遷移の理解がとても早くなりますので、ぜひ早いうちに学習しておきましょう。

Railsのroutes.rbとは

Railsのroutes.rbファイルは、ルーティングを登録するファイルです。

ルーティングというのは、ブラウザからRailsアプリへ渡される情報をもとに、登録された動きを行わせるための振り分け設定です。

つまり、routes.rbを見れば、そのRailsアプリがどんな要求に対してどんな動きをするのかが一目瞭然になると言えるでしょう。

なお、ここで書いている「ブラウザからの情報」というのは、「HTTPリクエスト」と呼び、ブラウザのアドレスバーに入力するURLも該当します。

一般的に「http://」などで始まるWebアドレスが代表例と言えまるでしょう。Railsアプリの実行時に「http://localhost:3000」とアドレスバーに入力するのも、ブラウザからのリクエストに応じて、Railsが初期画面を表示したルーティングの1つなのです。

Railsのroutes.rbファイルは、このルーティングをいくつも登録するファイルです。Railsアプリは、基本的にこのファイルの登録内容に従って動作しますので、routes.rbを眺めれば、Railsアプリの動きが見えるようになります。

なお、routes.rbに登録できるHTTPリクエストは、以下の5つです。

HTTPリクエスト	説明	例
GET	リソース（コンテンツ）の取得	サイトの表示
POST	リソースの作成や追加 リソース名が自動で付けられるため、常に追加となる	ブログ記事やコメントの投稿、写真の追加
PUT	リソースの作成と更新（置換） リソース名を指定するため、新規追加もしくは上書き置換になる	記事やコメントの追加、編集
PATCH	リソースの部分置換	記事のタイトルや本文だけの変更
DELETE	リソースの削除	記事やコメントの削除

すべて、ブラウザから見てどう動作するかという説明になっていますので、注意してください。（例えば、GETはブラウザがサーバーからリソースを取得するHTTPリクエストです）

routes.rbに記述できるルーティングの種類

じつは、routes.rbに記述できるルーティングには、大きく分類すると以下の3種類があります。

ルーティングの種類	説明
rootのルーティング	ルートURL（Railsアプリの基本のPath）を、特定のコントローラ内アクションへ割り当てる
リソースフルではないルーティング	あるHTTPリクエストを、特定のコントローラ内アクションへ割り当てる
リソースフルなルーティング	Rails推奨のルーティング方法で、必要なルーティングをまとめて割り当てる方法。他のWebアプリやサーバーとのやり取りに最適な7種類の割り当てを自動生成する

※実際のプログラムではこれらが混在していることが多いので、きちんと分けて考えるようにしましょう

なお、routes.rbのルーティングは、上から下へ順番にマッチングしていきます。そのため、同じ条件（HTTPリクエストとURL）のルーティングがあった場合、上にあるルーティングのみ有効になりますので、記載の順番には気を付けなければいけません。

rootのルーティング

まずは、Railsアプリの基本となる、rootのルーティングを説明しましょう。rootのルーティングは、Railsアプリを実行した瞬間の動作を決めるもので、何も設定しなければ、デフォルトのRailsページが表示されます。

rootの割り当てを行うことで、Railsアプリ実行時の動作を変更することができるのです。

なお、rootは、もっとも頻繁にアクセスされるURLです。そのため、リストのトップに記載することで、余計なマッチング処理が働かないようにしましょう。

rootとは

ルートというのは、Railsアプリを実行するにあたって、基本となる場所（Path）のことです。このPathを基本として、以降のURLが決められることになります。

例えば、Railsアプリをローカル環境へ設置したとき、実行時に「http://localhost:3000」と書きます。これがrootで、Railsアプリ内では「/」と表現することができます。

また、rootは、Railsアプリの格納されているディレクトリと対応しており、例えば、Railsアプリが「/rails/rails_test/」にある場合、rootはこのディレクトリを指すことになります。

つまり、サーバー上の「/rails/rails_test/phots/ファイル名」というURLを、Railsアプリでは「/phots/ファイル名」という記述で表現するわけです。

構文

rootの割り当てを行うためには、以下の構文を使います。

root to: ‘コントローラ名#アクション名’ # (1)
root ‘コントローラ名#アクション名’ # (2)

※(2)は、(1)の短縮形です。

rootの割り当てでは、記載していませんがGETリクエストが渡されていますので、コントロール内のアクションで生成した結果がブラウザへ返されます。

具体例

applicationコントローラのtopアクションへ割り当てた場合、以下のような記載になります。

Rails.application.routes.draw do
root ‘application#top’
end

（config/routes.rb）

もちろん、applicationコントローラ（app/controllers/application_controller.rb内のApplicationControllerクラス）にtopアクション（メソッド）がなければ、エラーが発生するでしょう。

リソースフルではないルーティング

ルート以外のURLやHTTPリクエストのルーティングを個々に指定したい場合には、こちらの方法を利用します。

記載パターンが多いですが、その分柔軟性が高くなっています。

ここでは、代表的な記載方法を紹介しましょう。

基本的な構文

基本的に、routes.rbには、以下の5つの方法のいずれかで、1行ごとに1つの動作を記載します。

HTTPリクエスト URL, to: ‘コントローラ名#アクション名’ # (1)
HTTPリクエスト URL, controller: ‘コントローラ名’, action: ‘アクション名’ # (2)
HTTPリクエスト URL, to: ‘コントローラ名#アクション名’ as: ‘ルート名’ # (3)
match URL, to: ‘コントローラ名#アクション名’ via: [:HTTPリクエスト, :HTTPリクエスト,,,] # (4)
match URL, to: ‘コントローラ名#アクション名’ via: :all # (5)

ルーティングの記載方法の基本は、(1)か(2)になります。

HTTPリクエストとURLに対して、コントローラ内のアクションを実行します。(1)と(2)の違いは、コントローラとアクションをまとめて書くか、別々に書くかだけです。

(3)はルーティングに特定の名前を付けるだけで、動作としては(1)と違いありません。（as:を利用すれば、他の記載方法のルーティングにも名前を付けることができます）

(4)と(5)は、あるURLと複数のHTTPリクエストのいずれかに対して、1つのコントローラ内アクションを割り当てています。

(5)はすべてのHTTPリクエスト（GET、POST、PUT、PATCH、DELETE）とURLの組み合わせに対して、1つのコントローラ内アクションを割り当てます。一見無意味に見えますが、アクション内で分岐した方が処理がシンプルになる場合がありますので、むしろ有用な場合もあります。

(4)は、URLと任意の数のHTTPリクエストのペアを、特定のコントローラ内アクションに割り当てます。使用シーンは(5)とよく似ていますが、必要最低限のHTTPリクエストを設定するという意味で、(4)の方がセキュリティ的に強固です。

パラメータを渡す

じつは、ルーティングによってアクションが処理されるとき、アクションにはコントローラ名とアクション名を収めた、ハッシュ値paramsが渡されています。

構文としては前述と変更ありませんが、URLの渡し方を工夫することで、アクションに対して引数（パラメータ）を渡すことができます。

前述の(1)の構文をベースにして、説明しましょう。

以下のようなディレクトリ構成のRailsアプリがあったとします。

上記のディレクトリ構成に対して、以下のようなルーティング設定を行うことで、/photsディレクトリへアクセスすると、controlコントロール内のactionアクションが処理されるように設定できるわけです。

GET ‘/phots’, to: ‘control#action’

このとき、actionアクションには、以下のようなハッシュ値paramsが渡されます。

{ controller: ‘control’, action: ‘action’ }

そのため、アクション内でparams[:controller]にアクセスすると’control’を取得できます。ただし、これではcontrolコントロール内のactionアクションという情報しかありませんので、それほど役には立たないでしょう。

もちろん、画面遷移するだけであれば問題ありませんが、ユーザーがfamilyやwork、その下の1や2などの下位ディレクトリへアクセスした場合に、それに合わせた動作をしたい場合は、「どこにアクセスしたのか」という情報が欲しいものです。

もちろん、以下のようにすれば、実現はできます。

GET ‘/phots/family’, to: ‘control#family_action’
GET ‘/phots/family/1’, to: ‘control#family1_action’
GET ‘/phots/family/2’, to: ‘control#family2_action’
GET ‘/phots/work’, to: ‘control#work_action’
GET ‘/phots/hobby’, to: ‘control#hobby_action’
:

ディレクトリ構成が固定であれば、これでも良いかもしれません。

しかし、もしディレクトリ構成が変化した場合、それに合わせてルーティング設定を追加し、アクションも追加しなければいけません。そんな回収を都度するのは、現実的ではありません。

このような要望に合わせて、URLの位置などをパラメータとしてアクションに渡すことができるのです。

例えば、以下のようにすれば、phots配下の2階層まで指定されたURLがすべてマッチし、actionアクションに割り当てられます。

GET ‘/phots/:child_path/:id’, to: ‘control#action’

そして、もし渡されたURLが’/phots/family/2’だった場合、actionアクションへ以下のようなハッシュ値paramsが渡されるのです。

{ controller: ‘control’, action: ‘action’, child_path: ‘family’, id: ‘2’ }

そのため、アクション内でparams[:child_path]やparams[:id]へアクセスすることで、URLの詳細を知ることができるわけです。場所が分かれば、アクションの中で分岐させることができるため、上述のようにroutes.rbファイルの記載が増えることはないわけです。

部分文字列やクエリ文字列も取得可能

前述のようなディレクトリ名そのものだけではなく、以下のようにすることで、ディレクトリ名の一部やクエリ文字列もパラメータとして取得することが可能です。

以下のようなルート設定をすることで、videosディレクトリの下2階層のURLについて、マッチすることができるでしょう。

GET ‘/videos/family(:child_id)/:id’, to: ‘control#action’

もし、渡されたURLが’/videos/family2/1’だった場合、actionアクションへ以下のようなハッシュ値paramsが渡されるのです。

{ controller: ‘control’, action: ‘action’, child_id: ‘2’, id: ‘1’ }

そして、渡されたURLにクエリ文字列が含まれる場合は、クエリ文字列もハッシュ値として追加されます。

URL：’/videos/family2/1?item=2′

{ controller: ‘control’, action: ‘action’, child_id: ‘2’, id: ‘1’, item: ‘2’ }

リソースフルなルーティング

リソースフルというのは、リソースベースのコントローラに対する共通のルーティングのことを指します。具体的には、あるリソースへアクセスするために、一般的に必要とされているindex、show、new、edit、create、update、destroyという7つのアクションへの割り当てを、自動的に行うことができるルーティングです。

なお、7つのアクションは、それぞれ次のような動作を表しています。

action	動作
index	一覧
show	個別詳細
new	作成
edit	編集
create	登録
update	更新
destroy	削除

リソースフルなルーティングを利用することで、7つのルーティングを1行で記載することができ、routes.rbが非常にシンプルになります。
※この手法は、他のWebサービスとの汎用的なアクセスができるRESTfulなルーティングが実現できるため、Railsはこの方法を推奨しています

構文

resources :リソース名 # (1)
resource :リソース名 # (2)

(1)と(2)の違いは、複数のリソースか、単数（1つ）のリソースかの違いです。

リソースフルなルーティングの中身

例えば、「videos」というリソースがあったとして、リソースフルなルーティングを行うのは、次の1行で済みます。

resources :videos

しかし、この1行は、実際には以下の7行が設定されているのと同じ意味を示します。

get ‘/videos’, to: ‘videos#index’
get ‘/videos/:id’, to: ‘videos#show’
get ‘/videos/new’, to: ‘videos#new
get ‘/videos/:id/edit’, to: ‘videos#edit
post ‘/videos’, to: ‘videos#create
patch ‘/videos/:id’, to: ‘videos#update’
delete ‘/videos/:id’, to: ‘videos#destroy’

単数形の「resource :video」を設定した場合は、リソース1つ分のルーティングになるため、以下の6行になります。

get ‘/video’, to: ‘videos#show’
get ‘/video/new’, to: ‘videos#new’
post ‘/video’, to: ‘videos#create’
get ‘/video/edit’, to: ‘videos#edit’
patch ‘/video’, to: ‘videos#update’
delete ‘/video’, to: ‘videos#destroy’

なお、リソースは1つですので、「:id」は使われていません。

必要最小限のアクションにする

リソースフルなルーティングを使うのが、Railsの公式なルーティング手法です。しかし、常にすべてのアクションが必要だとは限らないでしょう。

そういった場合に備えて、使用するアクションを限定したり、不要なものを外したりすることができるようになっています。

使用するアクションを限定するonly:オプション

リソースフルなルーティングに、only:オプションを付与することで、only:オプションで指定したアクションだけに限定することができます。

例えば、show、edit、destroyのみ有効にする場合は、以下のように記載します。

resources :videos only:[:show, :destroy]

配列に追記するアクションの数はいくつでもかまいません。

不要なものを削除するexcept:オプション

一部のアクションだけ無効にしたい場合は、except:オプションの方が分かりやすいでしょう。こちらは、only:オプションとは逆に、無効にしたいアクションだけを指定してやります。

「destroyアクションは使わせたくない」場合は、以下のような記載になります。

resources :videos only:[:destroy]

なお、only:オプションの例と同じ設定を、except:オプションで表現したい場合は、以下のようになります。

resources :videos only:[:index, :new, :edit, :create, :update]

※この場合はexcept:オプションの方が可読性が高くなりますので、一般的にこういった使い方はしません。

URL用ヘルパー

URL用ヘルパーというのは、リソースのURLを簡単な記述で取得することができる機能のことです。

リソースフルなルーティングを利用すると、URL用ヘルパー機能を利用することができます。

具体的には、リソース名から変数名が自動的に生成され、その変数を利用することで、URLを取得することができるのです。

URL用ヘルパーには、ルート以降のパスだけを返すpathヘルパー（リソース名_path）とpathヘルパーの値にプロトコル、ホスト名:ポート番号を加えたフルURLを返すurlヘルパー（リソース名_url）の2種類があります。

そして、それぞれ、以下の4種類の値を返すヘルパーが存在しています。

ヘルパー名称	得られるURL
リソース名_path リソース名_url	/リソース名
new_リソース名_path new_リソース名_url	/リソース名/new
edit_リソース名_path(:id) edit_リソース名_url(:id)	/リソース名/:id/edit
リソース名_path(:id) リソース名_url(:id)	/リソース名/:id

URL用ヘルパーをアクションなどで利用することで、プログラムコードの可読性を上げるだけではなく、ホストやルートパスが変更された場合に修正が不要になるという大きな利点があります。

まとめ

Railsのroutes.rbについて、基本となる使い方を説明しました。

ルーティングは、Railsアプリの導線を決めるとても重要なポイントで、この設定によってRailsアプリ全体の効率が違ってくることもあります。また、ルーティングを理解することで、Railsアプリの動きを把握することができますので、デバッグなどの解析作業もとても楽になります。

ルーティングは、Railsアプリの基本の1つですので、しっかりと押さえておきましょう。

・routesは、ブラウザからRailsアプリへ渡される情報をもとに、登録された動きを行わせるための振り分け設定
・HTTPリクエストとURLごとに、コントローラ内のアクションを振り分ける
・routes.rbのルーティングは、上から下へ順番にマッチングしている
・rootのルーティングで、Railsアプリの起動時の動作が決まる
・リソースフルではないルーティングは、個別でルーティングを指定するため、柔軟な割り当てが可能
・リソースフルなルーティングは、1行で一般的なルーティングを複数登録することができる
・ルーティングのURLのパスやクエリ文字列などを、パラメータとしてアクションへ渡すことができる
・リソースフルなルーティングでは、ヘルパーが使える

＼プログラミングスクールを比較／