railsguides.jp

目次

1. Railsルーターの目的
   • URLを実際のコードに割り振る
   • コードからパスやURLを生成する
2. リソースベースのルーティング: Railsのデフォルト
   • Web上のリソース
   • CRUD、動詞、アクション
   • パスとURL用ヘルパー
   • 複数のリソースを同時に定義する
   • 単数形リソース
   • コントローラの名前空間とルーティング
   • ネストしたリソース
   • ルーティングの「concern」機能
   • オブジェクトからパスとURLを作成する
   • RESTfulなアクションをさらに追加する
3. リソースフルでないルーティング
   • パラメータの割り当て
   • 動的なセグメント
   • 静的なセグメント
   • クエリ文字列
   • デフォルト設定を定義する
   • 名前付きルーティング
   • HTTP動詞を制限する
   • セグメントを制限する
   • リクエスト内容に応じて制限を加える
   • 高度な制限
   • ルーティンググロブとワイルドカードセグメント
   • リダイレクト
   • Rackアプリケーションにルーティングする
   • rootを使用する
   • Unicode文字列をルーティングで使用する
4. リソースフルルーティングをカスタマイズする
   • 使用するコントローラを指定する
   • 制限を指定する
   • 名前付きヘルパーをオーバーライドする
   • newセグメントやeditセグメントをオーバーライドする
   • 名前付きルーティングヘルパーにプレフィックスを追加する
   • ルーティングの作成を制限する
   • パスを変更する
   • 「単数形のフォーム」をオーバーライドする
   • 名前付きリソースで:asを使用する
   • 名前付きルーティングのパラメータをオーバーライドする
5. ルーティングの調査とテスト
   • 既存のルールを一覧表示する
   • ルーティングをテストする

1 Railsルーターの目的

Railsのルーターは受け取ったURLを認識し、適切なコントローラ内アクションに割り当てます。ルーターは、ビューでこれらのパスやURLを直接ハードコードすることを避けるためにパスやURLを生成することもできます。

1.1 URLを実際のコードに割り振る

Railsアプリケーションが以下のHTTPリクエストを受け取ったとします。

GET /patients/17

このリクエストは、特定のコントローラ内アクションにマッチさせるようルーターに要求しています。最初にマッチしたのが以下のルーティングだとします。

get '/patients/:id', to: 'patients#show'

このリクエストはpatientsコントローラのshowアクションに割り当てられ、paramsには{ id: '17' }ハッシュが含まれています。

1.2 コードからパスやURLを生成する

パスやURLを生成することもできます。たとえば、上のルーティングが以下のように変更されたとします。

get '/patients/:id', to: 'patients#show', as: 'patient'

そして、アプリケーションのコントローラに以下のコードがあるとします。

@patient = Patient.find(17)

上記に対応するビューは以下です。

<%= link_to 'Patient Record', patient_path(@patient) %>

これで、ルーターによって/patients/17というパスが生成されます。これを利用することでビューが改修しやすくなり、コードも読みやすくなります。このルーティングヘルパーではidを指定する必要がない点にご注目ください。

2 リソースベースのルーティング: Railsのデフォルト

リソースベースのルーティング (以下リソースルーティング) を使用することで、リソースベースで構成されたコントローラに対応する共通のルーティングを手軽に宣言できます。リソースフルなルーティングを宣言することで、コントローラのindex、show、new、edit、create、update、destroyアクションを個別に宣言しなくても1行で宣言が完了します。

2.1 Web上のリソース

ブラウザはRailsに対してリクエストを送信する際に、特定のHTTPメソッド (GET、POST、PATCH、PUT、DELETEなど) を使用して、URLに対するリクエストを作成します。上に述べたHTTPメソッドは、いずれもリソースに対して特定の操作の実行を指示するリクエストです。リソースルーティングでは、関連するさまざまなリクエストを1つのコントローラ内のアクションに割り当てます。

Railsアプリケーションが以下のHTTPリクエストを受け取ったとします。

DELETE /photos/17

このリクエストは、特定のコントローラ内アクションにマッピングさせるようルーターに要求しています。最初にマッチしたのが以下のルーティングだとします。

resources :photos

Railsはこのリクエストをphotosコントローラ内のdestroyアクションに割り当て、paramsハッシュに{ id: '17' }を含めます。

2.2 CRUD、動詞、アクション

Railsのリソースフルルーティングでは、(GET、PUTなどの) 各種HTTP動詞 (verb) と、コントローラ内アクションを指すURLが対応付けられます。1つのアクションは、データベース上での特定のCRUD (Create/Read/Update/Delete) 操作に対応付けられるルールになっています。たとえば、以下のようなルーティングが1つあるとします。

resources :photos

上の記述により、アプリケーション内に以下の7つのルーティングが作成され、いずれもPhotosコントローラに対応付けられます。

2.3 パスとURL用ヘルパー

リソースフルなルーティングを作成すると、アプリケーションのコントローラで多くのヘルパーが利用できるようになります。resources :photosというルーティングを例に取ってみましょう。

• photos_pathは/photosを返します
• new_photo_pathは/photos/newを返します
• edit_photo_path(:id)は/photos/:id/editを返します (edit_photo_path(10)であれば/photos/10/editが返されます)
• photo_path(:id)は/photos/:idを返します。 (photo_path(10)であれば/photos/10が返されます)

これらの_pathヘルパーには、それぞれに対応する_urlヘルパー (photos_urlなど) があります。_urlヘルパーは、_pathの前に現在のホスト名、ポート番号、パスのプレフィックスが追加されている点が異なります。

2.4 複数のリソースを同時に定義する

リソースをいくつも定義しなければならない場合は、以下のような略記法で一度に定義することでタイプ量を節約できます。

resources :photos, :books, :videos

上の記法は以下と完全に同一です。

resources :photos
resources :books
resources :videos

2.5 単数形リソース

場合によっては、ユーザーがページを表示する時にidを参照することのないリソースが使用されることがあります。たとえば、/profileでは常に「現在ログインしているユーザー自身」のプロファイルを表示し、他のユーザーidを参照する必要がないとします。このような場合には、単数形リソース (singular resource) を使用してshowアクションに (/profile/:idではなく) /profileを割り当てることができます。

get 'profile', to: 'users#show'

getの引数に文字列を渡す場合はコントローラ#アクション形式であることが前提ですが、getの引数にシンボルを渡すとアクションに直接割り当てられます。その場合は controller: を指定する必要があります。

get 'profile', action: :show, controller: 'users'

以下に記述するリソースフルなルーティングは

resource :geocoder

Geocodersコントローラに割り当てられた以下の6つのルーティングを作成します。

単数形のリソースフルなルーティングを使用すると、以下のヘルパーメソッドが生成されます。

• new_geocoder_pathは/geocoder/newを返します
• edit_geocoder_pathは/geocoder/editを返します
• geocoder_pathは/geocoderを返します。

複数形リソースの場合と同様に、単数形リソースでも_pathヘルパーに対応する_urlヘルパーが使用できます。_urlヘルパーは、_pathの前に現在のホスト名、ポート番号、パスのプレフィックスが追加されている点が異なります。

form_for @geocoder, url: geocoder_path do |f|

2.6 コントローラの名前空間とルーティング

コントローラを名前空間によってグループ化することもできます。最もよく使用される名前空間といえば、多数の管理用コントローラ群をまとめるAdmin::名前空間でしょう。これらのコントローラをapp/controllers/adminディレクトリに配置し、ルーティングでこれらをグループ化できます。

namespace :admin do
  resources :posts, :comments
end

上のルーティングにより、postsコントローラやcommentsコントローラへのルーティングが多数生成されます。たとえば、Admin::PostsController向けに作成されるルーティングは以下のとおりです。

例外的に、(/adminが前についていない) /postsをAdmin::PostsControllerにルーティングしたい場合は、以下のようにすることもできます。

scope module: 'admin' do
  resources :posts, :comments
end

以下のようにブロックを使用しない記述も可能です。

resources :posts, module: 'admin'

逆に、/admin/postsを (Admin::なしの) PostsControllerにルーティングしたい場合は、以下のようにします。

scope '/admin' do
  resources :posts, :comments
end

以下のようにブロックを使用しない記述も可能です。

resources :posts, path: '/admin/posts'

いずれの場合も、名前付きルート (named route)は、scopeを使用しなかった場合と同じであることにご注目ください。最後の例の場合は、以下のパスがPostsControllerに割り当てられます。

2.7 ネストしたリソース

論理上、他のリソースの配下に子リソースを配置することはよくあります。たとえば、Railsアプリケーションに以下のモデルがあるとします。

class Magazine < ActiveRecord::Base
  has_many :ads
end

class Ad < ActiveRecord::Base
  belongs_to :magazine
end

ルーティングをネストする (入れ子にする) ことで、この親子関係をルーティングで表すことができるようになります。上の例の場合、以下のようにルーティングを宣言することができます。

resources :magazines do
  resources :ads
end

上のルーティングによって、雑誌 (magazine) へのルーティングに加えて、広告 (ad) をAdsControllerにルーティングすることもできるようになりました。adへのURLにはmagazineもなければなりません。

ルーティングを作成すると、ルーティングヘルパーも作成されます。ヘルパーはmagazine_ads_urlやedit_magazine_ad_pathのような名前になります。これらのヘルパーは、最初のパラメータとしてMagazineモデルのインスタンスを1つ取ります (magazine_ads_url(@magazine))。

2.7.1 ネスティング回数の限界

ネストしたリソースの中でさらに別のリソースをネストすることは可能です。例：

resources :publishers do
  resources :magazines do
    resources :photos
  end
end

すぐ想像が付くと思いますが、ネストが深くなるとたちまち扱いが厄介になります。たとえば、上のルーティングはアプリケーションで以下のようなパスとして認識されます。

/publishers/1/magazines/2/photos/3

このURLに対応するルーティングヘルパーはpublisher_magazine_photo_urlとなります。このヘルパーを使用するには毎回3つの階層すべてでオブジェクトを指定する必要があります。ネスティングが深くなることでルーティングの扱いが困難になる問題については、Jamis Buckの有名な 記事 を参照してください。JamisはRailsアプリケーション設計上のよい経験則を提案しています。

2.7.2 「浅い」ネスト

前述したような深いネストを避けるひとつの方法として、コレクション (index/new/createのような、idを持たないアクション) だけを親のスコープの下で生成するという手法があります。このとき、メンバー (show/edit/update/destroyのような、idを必要とするアクション) をネストに含めないのがポイントです。これによりコレクションだけが階層化のメリットを受けられます。つまり、以下のように最小限の情報でリソースを一意に指定できるルーティングを作成するということです。

resources :posts do
  resources :comments, only: [:index, :new, :create]
end
resources :comments, only: [:show, :edit, :update, :destroy]

この方法は、ルーティングの記述を複雑にせず、かつ深いネストを作らないという絶妙なバランスを保っています。:shallowオプションを使用することで、上と同じ内容をさらに簡単に記述できます。

resources :posts do
  resources :comments, shallow: true
end

これによって生成されるルーティングは、最初の例と完全に同じです。親リソースで:shallowオプションを指定すると、すべてのネストしたリソースが浅くなります。

resources :posts, shallow: true do
  resources :comments
  resources :quotes
  resources :drafts
end

DSL (ドメイン固有言語) であるshallowメソッドをルーティングで使用すると、すべてのネストが浅くなるように内側にスコープを1つ作成します。これによって生成されるルーティングは、最初の例と完全に同じです。

shallow do
  resources :posts do
    resources :comments
    resources :quotes
    resources :drafts
  end
end

scopeメソッドには、「浅い」ルーティングをカスタマイズするためのオプションが2つあります。:shallow_pathオプションは、指定されたパラメータをメンバーのパスの冒頭にだけ追加します。

scope shallow_path: "sekret" do
  resources :posts do
    resources :comments, shallow: true
  end
end

上の場合、commentsリソースのルーティングは以下のようになります。

:shallow_prefixオプションを使用すると、指定されたパラメータを (パスではなく) 名前付きヘルパー名の冒頭に追加します。

scope shallow_prefix: "sekret" do
  resources :posts do
    resources :comments, shallow: true
  end
end

上の場合、commentsリソースのルーティングは以下のようになります。

2.8 ルーティングの「concern」機能

concernを使用することで、他のリソースやルーティング内で使いまわせる共通のルーティングを宣言することができます。concernは以下のように定義します。

concern :commentable do
  resources :comments
end

concern :image_attachable do
  resources :images, only: :index
end

concernを利用すると、同じようなルーティングを繰り返し記述せずに済み、複数のルーティング間で同じ動作を共有できます。

resources :messages, concerns: :commentable

resources :posts, concerns: [:commentable, :image_attachable]

上のコードは以下と同等です。

resources :messages do
  resources :comments
end

resources :posts do
  resources :comments
  resources :images, only: :index
end

concernはルーティング内のどのような場所にでも配置することができます。スコープや名前空間呼び出しでの使用法は以下のとおりです。

namespace :posts do
  concerns :commentable
end

2.9 オブジェクトからパスとURLを作成する

ルーティングヘルパーを使用する方法の他に、パラメータの配列からパスやURLを作成することもできます。例として、以下のようなルーティングがあるとします。

resources :magazines do
  resources :ads
end

magazine_ad_pathを使用すると、idを数字で渡す代りにMagazineとAdのインスタンスを引数として渡すことができます。

<%= link_to 'Ad details', magazine_ad_path(@magazine, @ad) %>

複数のオブジェクトが集まったセットに対してurl_forを使用することもできます。複数のオブジェクトを渡しても、適切なルーティングが自動的に決定されます。

<%= link_to 'Ad details', url_for([@magazine, @ad]) %>

上の場合、Railsは@magazineがMagazineであり、@adがAdであることを認識し、それに基づいてmagazine_ad_pathヘルパーを呼び出します。link_toなどのヘルパーでも、完全なurl_for呼び出しの代りに単にオブジェクトを渡すことができます。

<%= link_to 'Ad details', [@magazine, @ad] %>

1冊の雑誌にだけリンクしたいのであれば、以下のように書きます。

<%= link_to 'Magazine details', @magazine %>

それ以外のアクションであれば、配列の最初の要素にアクション名を挿入するだけで済みます。

<%= link_to 'Edit Ad', [:edit, @magazine, @ad] %>

これにより、モデルのインスタンスをURLとして扱うことができます。これはリソースフルなスタイルを採用する大きなメリットの1つです。

2.10 RESTfulなアクションをさらに追加する

デフォルトで作成されるRESTfulなルーティングは7つですが、7つでなければならないということはありません。必要であれば、コレクションやコレクションの各メンバーに対して適用されるリソースを追加することもできます。

2.10.1 メンバールーティングを追加する

メンバー (member) ルーティングを追加したい場合は、memberブロックをリソースブロックに1つ追加します。

resources :photos do
  member do
    get 'preview'
  end
end

上のルーティングはGETリクエストとそれに伴う/photos/1/previewを認識し、リクエストをPhotosコントローラのpreviewアクションにルーティングし、リソースid値をparams[:id]に渡します。同時に、preview_photo_urlヘルパーとpreview_photo_pathヘルパーも作成されます。

memberルーティングブロックの内側では、次に述べるHTTP動詞が指定されたルーティング名を認識できます。指定可能な動詞はget、patch、put、post、deleteです。memberルーティングが1つだけしかないのであれば、以下のようにルーティングで:onオプションを指定することでブロックを省略できます。

resources :photos do
  get 'preview', on: :member
end

:onオプションを省略しても同様のmemberルーティングが生成されます。この場合リソースidの値の取得にparams[:id]ではなくparams[:photo_id]を使用する点が異なります。

2.10.2 コレクションルーティングを追加する

ルーティングにコレクション (collection) を追加するには以下のようにします。

resources :photos do
  collection do
    get 'search'
  end
end

上のルーティングは、GETリクエスト+/photos/searchなどの (idを伴わない) パスを認識し、リクエストをPhotosコントローラのsearchアクションにルーティングします。このときsearch_photos_urlやsearch_photos_pathルーティングヘルパーも同時に作成されます。

collectionルーティングでもmemberルーティングのときと同様に:onオプションを使用できます。

resources :photos do
  get 'search', on: :collection
end

2.10.3 追加されたnewアクションへのルーティングを追加する

:onオプションを使用して、たとえば以下のように別のnewアクションを追加できます。

resources :comments do
  get 'preview', on: :new
end

上のようにすることで、GET + /comments/new/previewのようなパスが認識され、Commentsコントローラのpreviewアクションにルーティングされます。preview_new_comment_urlやpreview_new_comment_pathルーティングヘルパーも同時に作成されます。

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

Railsではリソースルーティングを行なう他に、任意のURLをアクションにルーティングすることもできます。この方式を使用する場合、リソースフルルーティングのような自動的なルーティンググループの生成は行われません。従って、アプリケーションで必要なルーティングを個別に設定することになります。

基本的にはリソースフルルーティングを使用すべきではありますが、このような単純なルーティングの方が適している箇所も多数あるはずです。リソースフルルーティングでは大袈裟過ぎる場合に、アプリケーションを無理にリソースフルなフレームワークに押し込める必要はありません。

シンプルルーティングは、特に従来形式のURLを新しいRailsのアクションに割り当てることがずっと簡単に行えるようになります。

3.1 パラメータの割り当て

通常のルーティングを設定するのであれば、RailsがルーティングをブラウザからのHTTPリクエストに割り当てるためのシンボルをいくつか渡します。それらのシンボルのうち、:controllerと:actionは特別です。:controllerはアプリケーションのコントローラへの割り当てを行い、:actionはそのコントローラの中にあるアクションへの割り当てを行います (訳注: 具体的なコントローラ名とアクション名を指定していない点にご注目ください)。以下のルーティングを例にとってみましょう。

get ':controller(/:action(/:id))'

ブラウザからの/photos/show/1リクエストが上のルーティングで処理される (他のルーティング設定にはマッチしなかったとします) と、Photosコントローラのshowアクションが呼び出され、URL末尾のパラメータ"1"へのアクセスはparams[:id]で行なえます。:actionと:idが必須パラメータではないことがかっこ () で示されているので、このルーティングは/photosをPhotosController#indexにルーティングすることもできます。

3.2 動的なセグメント

通常のルーティングの一部として、文字列を固定しない動的なセグメントを自由に使用できます。:controllerや:actionを除き、どんなものでもparamsの一部に含めてアクションに渡すことができます。以下のルーティングを設定したとします。

get ':controller/:action/:id/:user_id'

ブラウザからの/photos/show/1/2パスはPhotosコントローラのshowアクションに割り当てられます。params[:id]には"1"、params[:user_id]には"2"がそれぞれ保存されます。

get ':controller(/:action(/:id))', controller: /admin\/[^\/]+/

3.3 静的なセグメント

ルート作成時にコロンを付けなかった部分は、静的なセグメントとして固定文字列が指定されます。

get ':controller/:action/:id/with_user/:user_id'

上のルーティングは、/photos/show/1/with_user/2のようなパスにマッチします。with_userの部分は固定されています。このときアクションで使用できるparamsは { controller: 'photos', action: 'show', id: '1', user_id: '2' }となります。

3.4 クエリ文字列

クエリ文字列 (訳注: ?パラメータ名=値の形式でURLの末尾に置かれるパラメータ) で指定されているパラメータもすべてparamsに含まれます。以下のルーティングを例にとってみましょう。

get ':controller/:action/:id'

ブラウザからのリクエストで/photos/show/1?user_id=2というパスが渡されると、Photosコントローラのshowアクションに割り当てられます。このときのparamsは{ controller: 'photos', action: 'show', id: '1', user_id: '2' }となります。

3.5 デフォルト設定を定義する

:controllerシンボルや:actionシンボルは、ルーティング内で明示的に指定する必要はありません。これらは以下のようにデフォルトとして指定することができます。

get 'photos/:id', to: 'photos#show'

上のルーティングはブラウザからの/photos/12パスにマッチし、Photosコントローラのshowアクションに割り当てられます。

:defaultsオプションにハッシュを渡すことで、これ以外のデフォルト設定を定義することもできます。この定義は、動的セグメントとして指定していないパラメータに対しても適用されます。例:

get 'photos/:id', to: 'photos#show', defaults: { format: 'jpg' }

上のルーティングはphotos/12にマッチし、Photosコントローラのshowアクションに割り当てられ、params[:format]には"jpg"が設定されます。

3.6 名前付きルーティング

:asオプションを使用することで、どんなルーティングにも名前を指定できます。

get 'exit', to: 'sessions#destroy', as: :logout

上のルーティングではlogout_pathとlogout_urlがアプリケーションの名前付きヘルパーとして作成されます。logout_pathを呼び出すと/exitが返されます。

この方法を使用して、リソースとして定義されているルーティングを以下のように上書きすることもできます。

get ':username', to: 'users#show', as: :user

上のルーティングではuser_pathメソッドが生成され、コントローラ・ヘルパー・ビューでそれぞれ使用できるようになります。このメソッドは、/bobのようなユーザー名を持つルーティングに移動します。Usersコントローラのshowアクションの内部でparams[:username]にアクセスすると、ユーザー名を取り出すことができます。パラメータ名を:usernameにしたくない場合は、ルーティング定義の:usernameの部分を変更してください。

3.7 HTTP動詞を制限する

あるルーティングを特定のHTTP動詞に割り当てるために、通常はget、post、put、patch、deleteメソッドのいずれかを使用する必要があります。matchメソッドと:viaオプションを使用することで、複数のHTTP動詞に同時にマッチするルーティングを作成できます。

match 'photos', to: 'photos#show', via: [:get, :post]

via: :allを指定すると、すべてのHTTP動詞にマッチする特別なルーティングを作成できます。

match 'photos', to: 'photos#show', via: :all

3.8 セグメントを制限する

:constraintsオプションを使用すると、動的セグメントのURLフォーマットを特定の形式に制限することができます。

get 'photos/:id', to: 'photos#show', constraints: { id: /[A-Z]\d{5}/ }

上のルーティングは/photos/A12345のようなパスにはマッチしますが、/photos/893にはマッチしません。以下のようにもっと簡潔な方法で記述することもできます。

get 'photos/:id', to: 'photos#show', id: /[A-Z]\d{5}/

:constraintsでは正規表現を使用できますが、ここでは正規表現の「アンカー」は使用できないという制限があることにご注意ください。たとえば、以下のルーティングは無効です。

get '/:id', to: 'posts#show', constraints: {id: /^\d/}

対象となるルーティングはすべて初めからアンカーされているので、このようなアンカー表現を使用する必要はないはずです。

たとえば以下のルーティングでは、ルート (root) 名前空間を共有する際にpostsに対してto_paramが1-hello-worldのように数字で始まる値だけが使用できるようになっており、usersに対してto_paramがdavidのように数字で始まらない値だけが使用できるようになっています。

get '/:id', to: 'posts#show', constraints: { id: /\d.+/ }
get '/:username', to: 'users#show'

3.9 リクエスト内容に応じて制限を加える

また、Stringを返すRequestオブジェクトの任意のメソッドに基いてルーティングを制限することもできます。

リクエストに応じた制限は、セグメントを制限するときと同様の方法で指定することができます。

get 'photos', constraints: {subdomain: 'admin'}

ブロックフォームに対して制限を指定することもできます。

namespace :admin do
  constraints subdomain: 'admin' do
    resources :photos
  end
end

3.10 高度な制限

より高度な制限を使用したい場合、Railsで必要なmatches?に応答できるオブジェクトを渡す方法があります。例として、ブラックリストに記載されているすべてのユーザーをBlacklistControllerにルーティングしたいとします。この場合、以下のように設定します。

class BlacklistConstraint
  def initialize
    @ips = Blacklist.retrieve_ips
  end

  def matches?(request)
    @ips.include?(request.remote_ip)
  end
end

Rails.application.routes.draw do
  get '*path', to: 'blacklist#index',
    constraints: BlacklistConstraint.new
end

制限をラムダとして指定することもできます。

Rails.application.routes.draw do
  get '*path', to: 'blacklist#index',
    constraints: lambda { |request| Blacklist.retrieve_ips.include?(request.remote_ip) }
end

matches?メソッドおよびラムダはいずれも引数としてrequestオブジェクトを取ります。

3.11 ルーティンググロブとワイルドカードセグメント

ルーティンググロブ (route globbing) とはワイルドカード展開のことであり、ルーティングのある位置から下のすべての部分に特定のパラメータをマッチさせる際に使用します。例:

get 'photos/*other', to: 'photos#unknown'

上のルーティングはphotos/12や/photos/long/path/to/12にマッチし、params[:other]には"12"や"long/path/to/12"が設定されます。先頭にアスタリスク*が付いている部分を「ワイルドカードセグメント」と呼びます。

ワイルドカードセグメントはルーティングのどの部分でも使用できます。例:

get 'books/*section/:title', to: 'books#show'

上はbooks/some/section/last-words-a-memoirにマッチし、params[:section]には'some/section'が保存され、params[:title]には'last-words-a-memoir'が保存されます。

技術上は、1つのルーティングに2つ以上のワイルドカードセグメントを含めることは可能です。マッチャがセグメントをパラメータに割り当てる方法は直感的です。例:

get '*a/foo/*b', to: 'test#index'

上のルーティングはzoo/woo/foo/bar/bazにマッチし、params[:a]には'zoo/woo'が保存され、params[:b]には'bar/baz'が保存されます。

get '*pages', to: 'pages#show', format: false

get '*pages', to: 'pages#show', format: true

3.12 リダイレクト

ルーティングでredirectを使用すると、あるパスを他のあらゆるパスにリダイレクトできます。

get '/stories', to: redirect('/posts')

パスにマッチする動的セグメントを再利用してリダイレクトすることもできます。

get '/stories/:name', to: redirect('/posts/%{name}')

リダイレクトにブロックを渡すこともできます。このリダイレクトは、シンボル化されたパスパラメータとrequestオブジェクトを受け取ります。

get '/stories/:name', to: redirect {|path_params, req| "/posts/#{path_params[:name].pluralize}" }
get '/stories', to: redirect {|path_params, req| "/posts/#{req.subdomain}" }

ここで行われているリダイレクトは、HTTPステータスで言う「301 "Moved Permanently"」であることにご注意ください。一部のWebブラウザやプロキシサーバーはこの種のリダイレクトをキャッシュすることがあり、その場合リダイレクト前の古いページにはアクセスできなくなります。

どの場合であっても、ホスト (http://www.example.comなど) がURLの冒頭で指定されていない場合は、Railsは (以前のリクエストではなく) 現在のリクエストから詳細を取得します。

3.13 Rackアプリケーションにルーティングする

Postコントローラのindexアクションに対応する'posts#index'のような文字列の代りに、任意のRackアプリケーションをマッチャーのエンドポイントとして指定することができます。

match '/application.js', to: Sprockets, via: :all

Railsルーターから見れば、Sprocketsがcallに応答して[status, headers, body]を返す限り、ルーティング先がRackアプリケーションであるかアクションであるかは区別できません。これはvia: :allの適切な利用法です。というのは、適切と考えられるすべてのHTTP動詞をRackアプリケーションで扱えるようにできるからです。

3.14 rootを使用する

rootメソッドを使用することで、Railsがルート'/'とすべき場所を指定できます。

root to: 'pages#main'
root 'pages#main' # 上の省略形

rootルーティングは、ルーティングファイルの先頭に記述してください。rootは最もよく使用されるルーティングであり、最初にマッチする必要があるからです。

名前空間やスコープの内側にrootを置くこともできます。例:

namespace :admin do
  root to: "admin#index"
end

root to: "home#index"

3.15 Unicode文字列をルーティングで使用する

Unicode文字列をルーティングで直接使用することもできます。例:

get 'こんにちは', to: 'welcome#index'

4 リソースフルルーティングをカスタマイズする

ほとんどの場合、resources :postsのような指定を行ってデフォルトのルーティングやヘルパーを生成することで用は足りますが、もう少しルーティングをカスタマイズしたくなることもあります。Railsでは、リソースフルなヘルパーの一般的などの部分であっても事実上自由にカスタマイズ可能です。

4.1 使用するコントローラを指定する

:controllerオプションは、リソースで使用するコントローラを明示的に指定します。例:

resources :photos, controller: 'images'

上のルーティングは、/photosで始まるパスを認識しますが、ルーティング先をImagesコントローラにします。

名前空間内のコントローラは以下のように直接指定することができます。例:

resources :user_permissions, controller: 'admin/user_permissions'

上はAdmin::UserPermissionsにルーティングされます。

4.2 制限を指定する

:constraintsオプションを使用すると、暗黙で使用されるidに対してフォーマットを指定することができます。例:

resources :photos, constraints: {id: /[A-Z][A-Z][0-9]+/}

上の宣言は:idパラメータに制限を加え、指定した正規表現にのみマッチするようにします。従って、上の例では/photos/1のようなパスにはマッチしなくなります。代わって、/photos/RR27のようなパスにマッチするようになります。

ブロックフォームを使用することで、多数のルーティングに対して1つの制限をまとめて与えることもできます。

constraints(id: /[A-Z][A-Z][0-9]+/) do
  resources :photos
  resources :accounts
end

4.3 名前付きヘルパーをオーバーライドする

:asオプションを使用すると、名前付きルーティングヘルパーを上書きして異なる名前を使用できます。例:

resources :photos, as: 'images'

上のルーティングでは、/photosで始まるブラウザからのパスを認識し、このリクエストをPhotosコントローラにルーティングしますが、ヘルパーの命名に:asオプションの値が使用されます。

4.4 newセグメントやeditセグメントをオーバーライドする

:path_namesオプションを使用すると、パスに含まれている、自動生成された"new"セグメントや"edit"セグメントをオーバーライドできます。

resources :photos, path_names: { new: 'make', edit: 'change' }

これにより、ルーティングで以下のようなパスが認識できるようになります。

/photos/make
/photos/1/change

scope path_names: { new: 'make' } do
  # 残りすべてのルーティング
end

4.5 名前付きルーティングヘルパーにプレフィックスを追加する

:asオプションを使用することで、Railsがルーティングに対して生成する名前付きルーティングヘルパー名の冒頭に文字を追加できます (プレフィックス)。パススコープを使用するルーティング同士での名前の衝突を避けたい場合に使用してください。例:

scope 'admin' do
  resources :photos, as: 'admin_photos'
end

resources :photos

上のルーティングでは、admin_photos_pathやnew_admin_photo_pathなどのルーティングヘルパーが生成されます。

ルーティングヘルパーのグループにプレフィックスを追加するには、以下のようにscopeメソッドで:asオプションを使用します。

scope 'admin', as: 'admin' do
  resources :photos, :accounts
end

resources :photos, :accounts

上によって、admin_photos_pathとadmin_accounts_pathなどのルーティングが生成されます。これらは/admin/photosと/admin/accountsにそれぞれ割り当てられます。

名前付きパラメータを持つルーティングにプレフィックスを追加することもできます。

scope ':username' do
  resources :posts
end

上のルーティングにより、/bob/posts/1のような形式のURLを使用できるようになります。さらに、コントローラ、ヘルパー、ビューのいずれにおいても、このパスのusernameの部分に相当する文字列 (この場合であればbob) をparams[:username]で参照できます。

4.6 ルーティングの作成を制限する

Railsは、アプリケーション内のすべてのRESTfulルーティングに対してデフォルトで7つのアクション (index、show、new、create、edit、update、destroy) へのルーティングを作成します。:onlyオプションや:exceptオプションを使用することで、これらのルーティングを微調整できます。:onlyオプションは、指定されたルーティングだけを生成するよう指示します。

resources :photos, only: [:index, :show]

これで、/photosへのGETリクエストは成功し、/photos へのPOSTリクエスト (通常であればcreateアクションにルーティングされます) は失敗します。

:exceptオプションは逆に、指定したルーティングのみを生成 しない よう指示します。

resources :photos, except: :destroy

この場合、destroy (/photos/:idへのDELETEリクエスト) を除いて通常のルーティングが生成されます。

4.7 パスを変更する

scopeメソッドを使用することで、resourceによって生成されるデフォルトのパス名を変更できます。

scope(path_names: { new: 'neu', edit: 'bearbeiten' }) do
  resources :categories, path: 'kategorien'
end

上のようにすることで、以下のようなCategoriesコントローラへのルーティングが作成されます。

4.8 「単数形のフォーム」をオーバーライドする

あるリソースの「単数形のフォーム」を定義したい場合、Inflectorに活用形ルールを追加します。

ActiveSupport::Inflector.inflections do |inflect|
  inflect.irregular 'tooth', 'teeth'
end

4.9 名前付きリソースで:asを使用する

:asを使用すると、ネストしたルーティングヘルパー内のリソース用に自動生成された名前をオーバーライドできます。例:

resources :magazines do
  resources :ads, as: 'periodical_ads'
end

上のルーティングによって、magazine_periodical_ads_urlやedit_magazine_periodical_ad_pathなどのルーティングヘルパーが生成されます。

4.10 名前付きルーティングのパラメータをオーバーライドする

:paramオプションは、デフォルトのリソース識別子:id (ルーティングを生成するために使用される動的なセグメントの名前) をオーバーライドします。params[<:param>]を使用して、コントローラからそのセグメントにアクセスできます。

resources :videos, param: :identifier

     videos GET  /videos(.:format)                  videos#index
            POST /videos(.:format)                  videos#create
 new_videos GET  /videos/new(.:format)              videos#new
edit_videos GET  /videos/:identifier/edit(.:format) videos#edit

Video.find_by(identifier: params[:identifier])

関連するモデルの ActiveRecord::Base#to_param をオーバーライドしてURLを作成することができます。

class Video < ApplicationRecord
  def to_param
    identifier
  end
end

video = Video.find_by(identifier: "Roman-Holiday")
edit_videos_path(video) # => "/videos/Roman-Holiday"

5 ルーティングの調査とテスト

Railsには、ルーティングを調べる機能とテストする機能が備わっています。

5.1 既存のルールを一覧表示する

現在のアプリケーションで利用可能なルーティングをすべて表示するには、サーバーが development 環境で動作している状態でhttp://localhost:3000/rails/info/routesをブラウザで開きます。ターミナルでrake routesコマンドを実行しても同じ結果を得られます。

どちらの方法を使用した場合でも、routes.rbファイルに記載された順にルーティングが表示されます。1つのルーティングについて以下の情報が表示されます。

• ルーティング名 (あれば)
• 使用されているHTTP動詞 (そのルーティングがすべてのHTTP動詞に応答するのでない場合)
• マッチするURLパターン
• そのルーティングで使用するパラメータ

以下は、あるRESTfulルーティングに対してrake routesを実行した結果から抜粋したものです。

    users GET    /users(.:format)          users#index
          POST   /users(.:format)          users#create
new_user GET    /users/new(.:format)      users#new
edit_user GET    /users/:id/edit(.:format) users#edit

CONTROLLER環境変数を設定することで、ルーティング一覧の表示を特定のコントローラにマップされたものに制限することもできます。

$ CONTROLLER=users rake routes

5.2 ルーティングをテストする

アプリケーションの他の部分と同様、ルーティング部分もテスティング戦略に含めておくべきでしょう。Railsでは、テスティングを容易にするために3つのビルトインアサーション が用意されています。

• assert_generates
• assert_recognizes
• assert_routing

5.2.1 assert_generatesアサーション

assert_generatesは、特定のオプションの組み合わせを使用した場合に特定のパスが生成されること、そしてそれらがデフォルトのルーティングでもカスタムルーティングでも使用できることをテストするアサーション (assert, assertion: 主張・検証とも) です。例:

assert_generates '/photos/1', { controller: 'photos', action: 'show', id: '1' }
assert_generates '/about', controller: 'pages', action: 'about'

5.2.2 assert_recognizesアサーション

assert_recognizesはassert_generatesと逆方向のテスティングを行います。与えられたパスが認識可能であること、アプリケーションの特定の場所にルーティングされることをテストするアサーションです。例:

assert_recognizes({ controller: 'photos', action: 'show', id: '1' }, '/photos/1')

引数で:methodを使用してHTTP動詞を指定することもできます。

assert_recognizes({ controller: 'photos', action: 'create' }, { path: 'photos', method: :post })

5.2.3 assert_routingアサーション

assert_routingアサーションは、ルーティングを2つの観点 (与えられたパスによってオプションが生成されること、そのオプションによって元のパスが生成されること) からチェックします。つまり、assert_generatesとassert_recognizesの機能を組み合わせたものになります。

assert_routing({ path: 'photos', method: :post }, { controller: 'photos', action: 'create' })