2.1 The routes.rb File

Routes are defined in the file config/routes.rb

The Rails 4 Way

At runtime, the block is evaluated inside of an instance of the class ActionDispatch::Routing::Mapper.Through it you configure the Rails routing system.

At runtime, the block is evaluated inside of an instance of the class ActionDispatch::Routing::Mapper. Through it you configure the Rails routing system.
The routing system has to find a pattern match for a URL it’s trying to recognize or a parameters match for a URL it’s trying to generate. It does this by going through the routes in the order in which they’re defined;
that is, the order in which they appear in routes.rb. If a given route fails to match, the matching routine falls through to the next one. As soon as any route succeeds in providing the necessary match, the search ends.

2.2.1 Regular Routes

get `products/:id`, to: `products#show`
get `products/:id` => `products#show`

2.2.2 constraining Request Methods

match `products/:id` => `products#show`, via: :get

match `products/:id` => `products#show`, via: [:get, :post]

match `products/:id` => `products#show`, via: any

2.2.3 URL Patterns

get ":id" => "products#show"
# which would recognise  a URL like
# http://localhost:3000/8
# Th routing system would set params[:id] to 8

2.2.4 Segment Keys

The URL pattern string can contain parameters (denoted with a colon) and referred to as segment keys. In thefollowing route declaration, :id is a segment key.

get 'products/:id' => 'products#show'

What that means in the example is that the value of params[:id] will be set to the corresponding string in URL. You can access that value inside your products/show action.

When you generate a URL, you have to supply values that will attach to the segment keys inside the URL pattern string.

link_to"Products", 
  controller: "products", 
  action: "show",
  id: 1

It’s vital to understand that the call to link_to doesn’t know whether it’s supplying hard-coded or segment values. It just knows (or hopes!) that these three values, tied to these three keys, will suffice to pinpoint a route and therefore a pattern string, and therefore a blueprint for generating a URL dynamically.

2.2.5 Spotlight on the :id Field

Note that the treatment of the :id field in the URL is not magic; it’s just treated as a value with a name. If you wanted to, you could change the rule so that :id was :blah but then you’d have to do the following in your controller action:

@product=Product.find(params[:blah])

2.2.6 Optional Segment keys

# the contents within the parentheses are optional
match ':controller(/:action(/:id(.:format)))' , via: :any

2.2.7 Redirect Routes

get "/foo", to: redirect('/bar')

#contain a relative URL or a full URL
get "/google", to: redirect('http://google.com/')

# take a block, which receives the request parameter as its argument
match "/api/v1/:api", to:
  redirect {|params|  "api/v2/#{params[api].pluralize}"},
  via: :any

# with optional :status parameter
match "/api/v1/:api", to:
  redirect(status: 302) {|params|  "api/v2/#{params[api].pluralize}"},
  via: :any

2.2.8 The Format Segment

match ':controller(/:action(/:id(.:format)))', via: :any

# http://localhost:3000/products/show/3.json

def show
  @product = Product.find(params[:id])
  respond_to do |format|
    format.html
    format.json { render json: @product.to_json }
    format.any
  end
end

2.2.9 Routes as Rack Endpoints

The value of :to option can be referred to as a Reck Endpoint.

get "/hello", to: proc {|env| [200, {}, ["Helloworld"]] }

The router is very loosely coupled to controllers! The shorthand syntax (like "items#show") relies on the action method of controller classes to return a Rack endpoint that executes the action requested.

The ability to dispatch to a Rack-based application, such as one created with Sinatra, can be achieved using the mount method. The mount method accepts an :at option, which specifies the route the Rack-based application will map to.

class HelloApp < Sinatra::Base
  get "/" do
    "Hello World!"
  end
end

Example::Application.routes.draw do
  mount HelloApp, at: '/hello'
end

Alternatively, a shorthand form is also available:

mount HelloApp => '/hello'

2.2.10 Accept Header

You can also trigger a branching on respond_to by setting the Accept header in the request. When you do this, there’s no need to add the .:format part of the URL. (However, note that out in the real world, it’s difficult to get this technique to work reliably due to HTTP client/browser inconsistencies.)

2.2.11 Segment Key Constraints

Sometimes you want not only to recognize a route, but to recognize it at a finer-grained level than just what components or fields it has. You can do this through the use of the :constraint option (and possibly regular expressions).

get ':controller/show/:id' => :show, constraints: { :id => /\d+/ }
get ':controller/show/:id' => :show, id: /\d+/
get ':controller/show/:id' => :show_error

You can also check a grab-bag of other request attributes that return a string, such as :subdomain and :referrer. Matching methods of request that return numeric or boolean values are unsupported and will raise a somewhat cryptic exception during route matching.

# only allow users admin subdomain to do old-school routing
get ':controller/:action/:id' => :show, constraints: {subdomain: 'admin'}

If for some reason you need more powerful constraints checking, you have full access to the request object, by passing a block or any other object that responds to call as the value of :constraints like:

# protect records with id under 100
get'records/:id' => "records#protected",
  constraints: proc {|req| req.params[:id].to_i < 100 }

2.2.12 The Root Route

root :to => "welcome#index"
root :to => "pages#home"
# Shorthand syntax
root "user_sessions#new"

Routes are consulted, both for recognition and for generation, in the order they are defined in routes.rb. The search for a match ends when the first match is found, meaning that you have to watch out for false positives.

2. Routing - 2.2 The routes.rb File