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_todoesn’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.
