View Source Phoenix.Router (Phoenix v1.7.0-rc.0)
Defines a Phoenix router.
The router provides a set of macros for generating routes that dispatch to specific controllers and actions. Those macros are named after HTTP verbs. For example:
defmodule MyAppWeb.Router do
use Phoenix.Router
get "/pages/:page", PageController, :show
end
The get/3
macro above accepts a request to /pages/hello
and dispatches
it to PageController
's show
action with %{"page" => "hello"}
in
params
.
Phoenix's router is extremely efficient, as it relies on Elixir pattern matching for matching routes and serving requests.
routing
Routing
get/3
, post/3
, put/3
, and other macros named after HTTP verbs are used
to create routes.
The route:
get "/pages", PageController, :index
matches a GET
request to /pages
and dispatches it to the index
action in
PageController
.
get "/pages/:page", PageController, :show
matches /pages/hello
and dispatches to the show
action with
%{"page" => "hello"}
in params
.
defmodule PageController do
def show(conn, params) do
# %{"page" => "hello"} == params
end
end
Partial and multiple segments can be matched. For example:
get "/api/v:version/pages/:id", PageController, :show
matches /api/v1/pages/2
and puts %{"version" => "1", "id" => "2"}
in
params
. Only the trailing part of a segment can be captured.
Routes are matched from top to bottom. The second route here:
get "/pages/:page", PageController, :show
get "/pages/hello", PageController, :hello
will never match /pages/hello
because /pages/:page
matches that first.
Routes can use glob-like patterns to match trailing segments.
get "/pages/*page", PageController, :show
matches /pages/hello/world
and puts the globbed segments in params["page"]
.
GET /pages/hello/world
%{"page" => ["hello", "world"]} = params
Globs cannot have prefixes nor suffixes, but can be mixed with variables:
get "/pages/he:page/*rest", PageController, :show
matches
GET /pages/hello
%{"page" => "llo", "rest" => []} = params
GET /pages/hey/there/world
%{"page" => "y", "rest" => ["there" "world"]} = params
helpers
Helpers
Phoenix automatically generates a module Helpers
inside your router
by default, which contains named helpers to help developers generate and keep
their routes up to date. Helpers can be disabled by passing helpers: false
to use Phoenix.Router
.
See the Phoenix.VerifiedRoutes
documentation for ~p
based route generation
which is the preferred way to generate route paths and URLs with compile-time
verification.
Helpers are automatically generated based on the controller name. For example, the route:
get "/pages/:page", PageController, :show
will generate the following named helper:
MyAppWeb.Router.Helpers.page_path(conn_or_endpoint, :show, "hello")
"/pages/hello"
MyAppWeb.Router.Helpers.page_path(conn_or_endpoint, :show, "hello", some: "query")
"/pages/hello?some=query"
MyAppWeb.Router.Helpers.page_url(conn_or_endpoint, :show, "hello")
"http://example.com/pages/hello"
MyAppWeb.Router.Helpers.page_url(conn_or_endpoint, :show, "hello", some: "query")
"http://example.com/pages/hello?some=query"
If the route contains glob-like patterns, parameters for those have to be given as list:
MyAppWeb.Router.Helpers.page_path(conn_or_endpoint, :show, ["hello", "world"])
"/pages/hello/world"
The URL generated in the named URL helpers is based on the configuration for
:url
, :http
and :https
. However, if for some reason you need to manually
control the URL generation, the url helpers also allow you to pass in a URI
struct:
uri = %URI{scheme: "https", host: "other.example.com"}
MyAppWeb.Router.Helpers.page_url(uri, :show, "hello")
"https://other.example.com/pages/hello"
The named helper can also be customized with the :as
option. Given
the route:
get "/pages/:page", PageController, :show, as: :special_page
the named helper will be:
MyAppWeb.Router.Helpers.special_page_path(conn, :show, "hello")
"/pages/hello"
scopes-and-resources
Scopes and Resources
It is very common in Phoenix applications to namespace all of your routes under the application scope:
scope "/", MyAppWeb do
get "/pages/:id", PageController, :show
end
The route above will dispatch to MyAppWeb.PageController
. This syntax
is not only convenient for developers, since we don't have to repeat
the MyAppWeb.
prefix on all routes, but it also allows Phoenix to put
less pressure on the Elixir compiler. If instead we had written:
get "/pages/:id", MyAppWeb.PageController, :show
The Elixir compiler would infer that the router depends directly on
MyAppWeb.PageController
, which is not true. By using scopes, Phoenix
can properly hint to the Elixir compiler the controller is not an
actual dependency of the router. This provides more efficient
compilation times.
Scopes allow us to scope on any path or even on the helper name:
scope "/v1", MyAppWeb, host: "api." do
get "/pages/:id", PageController, :show
end
For example, the route above will match on the path "/api/v1/pages/1"
and the named route will be api_v1_page_path
, as expected from the
values given to scope/2
option.
Like all paths you can define dynamic segments that will be applied as parameters in the controller:
scope "/api/:version", MyAppWeb do
get "/pages/:id", PageController, :show
end
For example, the route above will match on the path "/api/v1/pages/1"
and in the controller the params
argument will have a map with the
key :version
with the value "v1"
.
Phoenix also provides a resources/4
macro that allows developers
to generate "RESTful" routes to a given resource:
defmodule MyAppWeb.Router do
use Phoenix.Router
resources "/pages", PageController, only: [:show]
resources "/users", UserController, except: [:delete]
end
Finally, Phoenix ships with a mix phx.routes
task that nicely
formats all routes in a given router. We can use it to verify all
routes included in the router above:
$ mix phx.routes
page_path GET /pages/:id PageController.show/2
user_path GET /users UserController.index/2
user_path GET /users/:id/edit UserController.edit/2
user_path GET /users/new UserController.new/2
user_path GET /users/:id UserController.show/2
user_path POST /users UserController.create/2
user_path PATCH /users/:id UserController.update/2
PUT /users/:id UserController.update/2
One can also pass a router explicitly as an argument to the task:
$ mix phx.routes MyAppWeb.Router
Check scope/2
and resources/4
for more information.
pipelines-and-plugs
Pipelines and plugs
Once a request arrives at the Phoenix router, it performs a series of transformations through pipelines until the request is dispatched to a desired route.
Such transformations are defined via plugs, as defined in the Plug specification. Once a pipeline is defined, it can be piped through per scope.
For example:
defmodule MyAppWeb.Router do
use Phoenix.Router
pipeline :browser do
plug :fetch_session
plug :accepts, ["html"]
end
scope "/" do
pipe_through :browser
# browser related routes and resources
end
end
Phoenix.Router
imports functions from both Plug.Conn
and Phoenix.Controller
to help define plugs. In the example above, fetch_session/2
comes from Plug.Conn
while accepts/2
comes from Phoenix.Controller
.
Note that router pipelines are only invoked after a route is found. No plug is invoked in case no matches were found.
how-to-organize-my-routes
How to organize my routes?
In Phoenix, we tend to define several pipelines, that provide specific
functionality. For example, the pipeline :browser
above includes plugs
that are common for all routes that are meant to be accessed by a browser.
Similarly, if you are also serving :api
requests, you would have a separate
:api
pipeline that validates information specific to your endpoints.
Perhaps more importantly, it is also very common to define pipelines specific to authentication and authorization. For example, you might have a pipeline that requires all users are authenticated. Another pipeline may enforce only admin users can access certain routes.
Once your pipelines are defined, you reuse the pipelines in the desired scopes, grouping your routes around their pipelines. For example, imagine you are building a blog. Anyone can read a post, but only authenticated users can create them. Your routes could look like this:
pipeline :browser do
plug :fetch_session
plug :accepts, ["html"]
end
pipeline :auth do
plug :ensure_authenticated
end
scope "/" do
pipe_through [:browser]
get "/posts", PostController, :index
get "/posts/:id", PostController, :show
end
scope "/" do
pipe_through [:browser, :auth]
get "/posts/new", PostController, :new
post "/posts", PostController, :create
end
Note in the above how the routes are split across different scopes. While the separation can be confusing at first, it has one big upside: it is very easy to inspect your routes and see all routes that, for example, require authentication and which ones do not. This helps with auditing and making sure your routes have the proper scope.
You can create as few or as many scopes as you want. Because pipelines are reusable across scopes, they help encapsulate common functionality and you can compose them as necessary on each scope you define.
Link to this section Summary
Reflection
Returns the compile-time route info and runtime path params for a request.
Returns the full alias with the current scope's aliased prefix.
Functions
Generates a route to handle a connect request to the given path.
Generates a route to handle a delete request to the given path.
Forwards a request at the given path to a plug.
Generates a route to handle a get request to the given path.
Generates a route to handle a head request to the given path.
Generates a route match based on an arbitrary HTTP method.
Generates a route to handle a options request to the given path.
Generates a route to handle a patch request to the given path.
Defines a list of plugs (and pipelines) to send the connection through.
Defines a plug pipeline.
Defines a plug inside a pipeline.
Generates a route to handle a post request to the given path.
Generates a route to handle a put request to the given path.
Defines "RESTful" routes for a resource.
Returns all routes information from the given router.
Defines a scope in which routes can be nested.
Define a scope with the given path.
Defines a scope with the given path and alias.
Returns the full path with the current scope's path prefix.
Generates a route to handle a trace request to the given path.
Link to this section Reflection
Returns the compile-time route info and runtime path params for a request.
The path
can be either a string or the path_info
segments.
A map of metadata is returned with the following keys:
:log
- the configured log level. For example:debug
:path_params
- the map of runtime path params:pipe_through
- the list of pipelines for the route's scope, for example[:browser]
:plug
- the plug to dispatch the route to, for exampleAppWeb.PostController
:plug_opts
- the options to pass when calling the plug, for example::index
:route
- the string route pattern, such as"/posts/:id"
examples
Examples
iex> Phoenix.Router.route_info(AppWeb.Router, "GET", "/posts/123", "myhost")
%{
log: :debug,
path_params: %{"id" => "123"},
pipe_through: [:browser],
plug: AppWeb.PostController,
plug_opts: :show,
route: "/posts/:id",
}
iex> Phoenix.Router.route_info(MyRouter, "GET", "/not-exists", "myhost")
:error
Returns the full alias with the current scope's aliased prefix.
Useful for applying the same short-hand alias handling to other values besides the second argument in route definitions.
examples
Examples
scope "/", MyPrefix do
get "/", ProxyPlug, controller: scoped_alias(__MODULE__, MyController)
end
Link to this section Functions
Generates a route to handle a connect request to the given path.
connect("/events/:id", EventController, :action)
See match/5
for options.
Generates a route to handle a delete request to the given path.
delete("/events/:id", EventController, :action)
See match/5
for options.
Forwards a request at the given path to a plug.
All paths that match the forwarded prefix will be sent to the forwarded plug. This is useful for sharing a router between applications or even breaking a big router into smaller ones. The router pipelines will be invoked prior to forwarding the connection.
However, we don't advise forwarding to another endpoint. The reason is that plugs defined by your app and the forwarded endpoint would be invoked twice, which may lead to errors.
examples
Examples
scope "/", MyApp do
pipe_through [:browser, :admin]
forward "/admin", SomeLib.AdminDashboard
forward "/api", ApiRouter
end
Generates a route to handle a get request to the given path.
get("/events/:id", EventController, :action)
See match/5
for options.
Generates a route to handle a head request to the given path.
head("/events/:id", EventController, :action)
See match/5
for options.
Generates a route match based on an arbitrary HTTP method.
Useful for defining routes not included in the builtin macros.
The catch-all verb, :*
, may also be used to match all HTTP methods.
options
Options
:as
- configures the named helper exclusively. If false, does not generate a helper.:alias
- configure if the scope alias should be applied to the route. Defaults to true, disables scoping if false.:log
- the level to log the route dispatching under, may be set to false. Defaults to:debug
:private
- a map of private data to merge into the connection when a route matches:assigns
- a map of data to merge into the connection when a route matches:metadata
- a map of metadata used by the telemetry events and returned byroute_info/4
:warn_on_verify
- the boolean for whether matches to this route trigger an unmatched route warning forPhoenix.VerifiedRoutes
. Useful to ignore an otherwise catch-all route definition from being matched when verifying routes. Defaultstrue
.
examples
Examples
match(:move, "/events/:id", EventController, :move)
match(:*, "/any", SomeController, :any)
Generates a route to handle a options request to the given path.
options("/events/:id", EventController, :action)
See match/5
for options.
Generates a route to handle a patch request to the given path.
patch("/events/:id", EventController, :action)
See match/5
for options.
Defines a list of plugs (and pipelines) to send the connection through.
See pipeline/2
for more information.
Defines a plug pipeline.
Pipelines are defined at the router root and can be used from any scope.
examples
Examples
pipeline :api do
plug :token_authentication
plug :dispatch
end
A scope may then use this pipeline as:
scope "/" do
pipe_through :api
end
Every time pipe_through/1
is called, the new pipelines
are appended to the ones previously given.
Defines a plug inside a pipeline.
See pipeline/2
for more information.
Generates a route to handle a post request to the given path.
post("/events/:id", EventController, :action)
See match/5
for options.
Generates a route to handle a put request to the given path.
put("/events/:id", EventController, :action)
See match/5
for options.
See resources/4
.
See resources/4
.
Defines "RESTful" routes for a resource.
The given definition:
resources "/users", UserController
will include routes to the following actions:
GET /users
=>:index
GET /users/new
=>:new
POST /users
=>:create
GET /users/:id
=>:show
GET /users/:id/edit
=>:edit
PATCH /users/:id
=>:update
PUT /users/:id
=>:update
DELETE /users/:id
=>:delete
options
Options
This macro accepts a set of options:
:only
- a list of actions to generate routes for, for example:[:show, :edit]
:except
- a list of actions to exclude generated routes from, for example:[:delete]
:param
- the name of the parameter for this resource, defaults to"id"
:name
- the prefix for this resource. This is used for the named helper and as the prefix for the parameter in nested resources. The default value is automatically derived from the controller name, i.e.UserController
will have name"user"
:as
- configures the named helper exclusively:singleton
- defines routes for a singleton resource that is looked up by the client without referencing an ID. Read below for more information
singleton-resources
Singleton resources
When a resource needs to be looked up without referencing an ID, because
it contains only a single entry in the given context, the :singleton
option can be used to generate a set of routes that are specific to
such single resource:
GET /user
=>:show
GET /user/new
=>:new
POST /user
=>:create
GET /user/edit
=>:edit
PATCH /user
=>:update
PUT /user
=>:update
DELETE /user
=>:delete
Usage example:
resources "/account", AccountController, only: [:show], singleton: true
nested-resources
Nested Resources
This macro also supports passing a nested block of route definitions. This is helpful for nesting children resources within their parents to generate nested routes.
The given definition:
resources "/users", UserController do
resources "/posts", PostController
end
will include the following routes:
user_post_path GET /users/:user_id/posts PostController :index
user_post_path GET /users/:user_id/posts/:id/edit PostController :edit
user_post_path GET /users/:user_id/posts/new PostController :new
user_post_path GET /users/:user_id/posts/:id PostController :show
user_post_path POST /users/:user_id/posts PostController :create
user_post_path PATCH /users/:user_id/posts/:id PostController :update
PUT /users/:user_id/posts/:id PostController :update
user_post_path DELETE /users/:user_id/posts/:id PostController :delete
Returns all routes information from the given router.
Defines a scope in which routes can be nested.
examples
Examples
scope path: "/api/v1", alias: API.V1 do
get "/pages/:id", PageController, :show
end
The generated route above will match on the path "/api/v1/pages/:id"
and will dispatch to :show
action in API.V1.PageController
. A named
helper api_v1_page_path
will also be generated.
options
Options
The supported options are:
:path
- a string containing the path scope.:as
- a string or atom containing the named helper scope. When set to false, it resets the nested helper scopes.:alias
- an alias (atom) containing the controller scope. When set to false, it resets all nested aliases.:host
- a string or list of strings containing the host scope, or prefix host scope, ie"foo.bar.com"
,"foo."
:private
- a map of private data to merge into the connection when a route matches:assigns
- a map of data to merge into the connection when a route matches:log
- the level to log the route dispatching under, may be set to false. Defaults to:debug
Define a scope with the given path.
This function is a shortcut for:
scope path: path do
...
end
examples
Examples
scope "/v1", host: "api." do
get "/pages/:id", PageController, :show
end
Defines a scope with the given path and alias.
This function is a shortcut for:
scope path: path, alias: alias do
...
end
examples
Examples
scope "/v1", API.V1, host: "api." do
get "/pages/:id", PageController, :show
end
Returns the full path with the current scope's path prefix.
Generates a route to handle a trace request to the given path.
trace("/events/:id", EventController, :action)
See match/5
for options.