◆当サイトで人気のプログラミング教室のおすすめランキングはこちら!
プログラミングは独学では非効率で、時間を無駄にするリスクがあります。効率的なカリキュラムで学べるスクールを受講しましょう。

DMM WEBCAMP【マンツーマンサポート】1ヶ月短期集中でプログラミングを学ぶスクール
1ヶ月通い放題・メンター常駐の教室環境でプログラミングを学びたい方!
TechAcademyオンラインで開講しているプログラミングスクール
オンラインでどこでも学べる!/教室に行くのが忙しい人でも安心!
TECH::CAMP教養としてのITスキルを学べるスクール
Webデザイン/AI(人工知能)/IOS/Androidアプリ制作/VRを学びたい方!
DMM WEBCAMP PRO転職保証付き!エンジニアとして転職したい人におすすめ!
未経験からプロのエンジニアへ3ヶ月で転職する為のスクールです!
1月生募集中!当社人気の転職保証コース
プログラミング学習から転職成功まで導く、当社人気のDMM WEBCAMP PROコース。
12月生は満員となっております。1月生募集に向け、お早めの申込みをオススメします。
プログラミング未経験でもエンジニア転職を絶対成功させたい
スキルを身に着けて人生を自ら切り開きたい
上記にあてはまる方は、ぜひご検討ください!

はじめに

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)のルーティングがあった場合、上にあるルーティングのみ有効になりますので、記載の順番には気を付けなければいけません。

未経験から上京し、エンジニアとしてチームラボグループに転職!【WebCampPro卒業生インタビュー】

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アクション(メソッド)がなければ、エラーが発生するでしょう。

コツコツ独学×スクールで実践。未経験からエンジニアに転職!【WebCamp卒業生インタビュー】

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

ルート以外の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/
│ ├family/
│ │ ├1/
│ │ ├2/
│ │ └3/
│ ├work/
│ │ └1/
│ └hobby/
│ ├1/
│ └2/
└videos/
├family1/
│ ├1/
│ └2/
└family2/
├1/
└2/

上記のディレクトリ構成に対して、以下のようなルーティング設定を行うことで、/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ファイルの記載が増えることはないわけです。

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

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

クエリ文字というのは、URLの末尾に負荷される「?パラメータ名=値」という文字列です。

以下のようなルート設定をすることで、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' }

“未経験”でもたった1ヶ月で営業からエンジニアとして転職!『WebCamp』受講者インタビュー

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

リソースフルというのは、リソースベースのコントローラに対する共通のルーティングのことを指します。具体的には、あるリソースへアクセスするために、一般的に必要とされている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]

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

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のパスやクエリ文字列などを、パラメータとしてアクションへ渡すことができる
・リソースフルなルーティングでは、ヘルパーが使える

DMM WEBCAMP ONLINE/プログラミングコースについて

WEBCAMPでは、「どこでも学べる」オンラインコースを開講しています。

初心者・未経験の方でもわずか1ヶ月でプログラミングの基礎を学び、アプリケーション開発をすることができます。

DMM WEBCAMP ONLINEが選ばれる3つの理由

1.学習の仕方がわからなくても安心!初心者に寄り添った学習カリキュラム

これから学習を始める初心者の方や、独学で挫折してしまった方に向けて、アプリケーション作成をゴールとする一気通貫したカリキュラムを提供しています。2500名を輩出しているWebCampだからこその教室でのリアルな受講生の声を反映し、オンラインコースでも初心者に寄り添った学習体験をご提供いたします。

2.つまずいたらすぐ解決!プロのエンジニアに質問し放題

プログラミング学習で挫折する理由の多くは「つまずいた時に聞ける人がいない」ことです。オンラインコースでは、現役エンジニアやプロ講師に、すぐにチャットでの質問が可能です。つまずきをすぐに解消できるので、挫折せずに学習を継続することができます

3.1ヶ月間で終わらなくても大丈夫!カリキュラムは"卒業後"も"無料"で利用可能

受講したいけど、仕事が急に忙しくなるかもしれないから受講するか迷っている・・・そんな方も多いのではないでしょうか?ご安心ください。カリキュラムは期間終了後も「無料」で使うことができます。また、しっかり学習時間を確保した方も、振り返って学習することでプログラミングスキルがご自身に馴染んできます。

▼まずは無料でWEBデザインのカリキュラムを体験しよう!

【インタビュー】1ヶ月でRubyをゼロから学び、Webエンジニアとして転職!

ブラジルから帰国し技術をつけようとRubyエンジニアを目指してWebCampでRubyを学び、見事Webエンジニアとして転職を果たした田中さんにお話を伺いました。

Rubyの学習がしたい。基礎をしっかりと理解したい

転職のサポートがほしい

と考えている方はぜひお読み下さい。

【WebCamp卒業生インタビュー】1ヶ月でRubyをゼロから学び、Webエンジニアとして転職!

おすすめの記事