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

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

Why the macros?

Phoenix does its best to keep the usage of macros low. You may have noticed, however, that the Phoenix.Router relies heavily on macros. Why is that?

We use get, post, put, and delete to define your routes. We use macros for two purposes:

• They define the routing engine, used on every request, to choose which controller to dispatch the request to. Thanks to macros, Phoenix compiles all of your routes to a single case-statement with pattern matching rules, which is heavily optimized by the Erlang VM

• For each route you define, we also define metadata to implement Phoenix.VerifiedRoutes. As we will soon learn, verified routes allows to us to reference any route as if it is a plain looking string, except it is verified by the compiler to be valid (making it much harder to ship broken links, forms, mails, etc to production)

In other words, the router relies on macros to build applications that are faster and safer. Also remember that macros in Elixir are compile-time only, which gives plenty of stability after the code is compiled. Phoenix also provides introspection for all defined routes via mix phx.routes.

Generating routes

For generating routes inside your application, 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.

Phoenix also supports generating function helpers, which was the default mechanism in Phoenix v1.6 and earlier. We will explore it next.

Helpers (deprecated)

Phoenix 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.

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

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

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?

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. Since routes are matched top to bottom, it is recommended to place the authenticated/authorized routes before the less restricted routes to ensure they are matched first.

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, :auth]

  get "/posts/new", PostController, :new
  post "/posts", PostController, :create
end

scope "/" do
  pipe_through [:browser]

  get "/posts", PostController, :index
  get "/posts/:id", PostController, :show
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.