Package gorilla/mux implements a request router and dispatcher.
The name mux stands for "HTTP request multiplexer". Like the standard
http.ServeMux, mux.Router matches incoming requests against a list of
registered routes and calls a handler for the route that matches the URL
or other conditions. The main features are:
* Requests can be matched based on URL host, path, path prefix, schemes,
header and query values, HTTP methods or using custom matchers.
* URL hosts and paths can have variables with an optional regular
expression.
* Registered URLs can be built, or "reversed", which helps maintaining
references to resources.
* Routes can be used as subrouters: nested routes are only tested if the
parent route matches. This is useful to define groups of routes that
share common conditions like a host, a path prefix or other repeated
attributes. As a bonus, this optimizes request matching.
* It implements the http.Handler interface so it is compatible with the
standard http.ServeMux.
Let's start registering a couple of URL paths and handlers:
Package `gorilla/mux` implements a request router and dispatcher.
func main() {
The name mux stands for "HTTP request multiplexer". Like the standard `http.ServeMux`, `mux.Router` matches incoming requests against a list of registered routes and calls a handler for the route that matches the URL or other conditions. The main features are:
r := mux.NewRouter()
r.HandleFunc("/", HomeHandler)
r.HandleFunc("/products", ProductsHandler)
r.HandleFunc("/articles", ArticlesHandler)
http.Handle("/", r)
}
Here we register three routes mapping URL paths to handlers. This is
* Requests can be matched based on URL host, path, path prefix, schemes, header and query values, HTTP methods or using custom matchers.
equivalent to how http.HandleFunc() works: if an incoming request URL matches
* URL hosts and paths can have variables with an optional regular expression.
one of the paths, the corresponding handler is called passing
* Registered URLs can be built, or "reversed", which helps maintaining references to resources.
(http.ResponseWriter, *http.Request) as parameters.
* Routes can be used as subrouters: nested routes are only tested if the parent route matches. This is useful to define groups of routes that share common conditions like a host, a path prefix or other repeated attributes. As a bonus, this optimizes request matching.
* It implements the `http.Handler` interface so it is compatible with the standard `http.ServeMux`.
Paths can have variables. They are defined using the format {name} or
Let's start registering a couple of URL paths and handlers:
{name:pattern}. If a regular expression pattern is not defined, the matched
variable will be anything until the next slash. For example:
The names are used to create a map of route variables which can be retrieved
Here we register three routes mapping URL paths to handlers. This is equivalent to how `http.HandleFunc()` works: if an incoming request URL matches one of the paths, the corresponding handler is called passing (`http.ResponseWriter`, `*http.Request`) as parameters.
calling mux.Vars():
vars := mux.Vars(request)
Paths can have variables. They are defined using the format `{name}` or `{name:pattern}`. If a regular expression pattern is not defined, the matched variable will be anything until the next slash. For example:
category := vars["category"]
And this is all you need to know about the basic usage. More advanced options
...and finally, it is possible to combine several matchers in a single route:
...and finally, it is possible to combine several matchers in a single route:
r.HandleFunc("/products", ProductsHandler).
```go
Host("www.example.com").
r.HandleFunc("/products", ProductsHandler).
Methods("GET").
Host("www.example.com").
Schemes("http")
Methods("GET").
Schemes("http")
```
Setting the same matching conditions again and again can be boring, so we have
Setting the same matching conditions again and again can be boring, so we have a way to group several routes that share the same requirements. We call it "subrouting".
a way to group several routes that share the same requirements.
We call it "subrouting".
For example, let's say we have several URLs that should only match when the
For example, let's say we have several URLs that should only match when the host is `www.example.com`. Create a route for that host and get a "subrouter" from it:
host is `www.example.com`. Create a route for that host and get a "subrouter"
The three URL paths we registered above will only be tested if the domain is
The three URL paths we registered above will only be tested if the domain is `www.example.com`, because the subrouter is tested first. This is not only convenient, but also optimizes request matching. You can create subrouters combining any attribute matchers accepted by a route.
`www.example.com`, because the subrouter is tested first. This is not
only convenient, but also optimizes request matching. You can create
subrouters combining any attribute matchers accepted by a route.
Subrouters can be used to create domain or path "namespaces": you define
Subrouters can be used to create domain or path "namespaces": you define subrouters in a central place and then parts of the app can register its paths relatively to a given subrouter.
subrouters in a central place and then parts of the app can register its
paths relatively to a given subrouter.
There's one more thing about subroutes. When a subrouter has a path prefix,
There's one more thing about subroutes. When a subrouter has a path prefix, the inner routes use it as base for their paths:
Routes can be named. All routes that define a name can have their URLs built,
Routes can be named. All routes that define a name can have their URLs built, or "reversed". We define a name calling `Name()` on a route. For example:
or "reversed". We define a name calling Name() on a route. For example:
To build a URL, get the route and call the URL() method, passing a sequence of
To build a URL, get the route and call the `URL()` method, passing a sequence of key/value pairs for the route variables. For the previous route, we would do:
key/value pairs for the route variables. For the previous route, we would do:
All variables defined in the route are required, and their values must
All variables defined in the route are required, and their values must conform to the corresponding patterns. These requirements guarantee that a generated URL will always match a registered route -- the only exception is for explicitly defined "build-only" routes which never match.
conform to the corresponding patterns. These requirements guarantee that a
generated URL will always match a registered route -- the only exception is
for explicitly defined "build-only" routes which never match.
Regex support also exists for matching Headers within a route. For example, we could do:
Regex support also exists for matching Headers within a route. For example, we could do:
...and the route will match both requests with a Content-Type of `application/json` as well as
```
`application/text`
There's also a way to build only the URL host or path for a route:
...and the route will match both requests with a Content-Type of `application/json` as well as `application/text`
use the methods URLHost() or URLPath() instead. For the previous route,
we would do:
// "http://news.domain.com/"
There's also a way to build only the URL host or path for a route: use the methods `URLHost()` or `URLPath()` instead. For the previous route, we would do:
Matt Silverlock
10 years ago