Routing

Package routing provides high performance and powerful HTTP routing capabilities.

Package rata provides three things: Routes, a Router, and a RequestGenerator. Routes are structs that define which Method and Path each associated http handler should respond to. Unlike many router implementations, the routes and the handlers are defined separately. This allows for the routes to be reused in multiple contexts. For example, a proxy server and a backend server can be created by having one set of Routes, but two sets of Handlers (one handler that proxies, another that serves the request). Likewise, your client code can use the routes with the RequestGenerator to create requests that use the same routes. Then, if the routes change, unit tests in the client and proxy service will warn you of the problem. This contract helps components stay in sync while relying less on integration tests. For example, let's imagine that you want to implement a "pet" resource that allows you to view, create, update, and delete which pets people own. Also, you would like to include the owner_id and pet_id as part of the URL path. First off, the routes might look like this: On the server, create a matching set of http handlers, one for each route: You can create a router by mixing the routes and handlers together: The router is just an http.Handler, so it can be used to create a server in the usual fashion: The handlers can obtain parameters derived from the URL path: Meanwhile, on the client side, you can create a request generator: You can use the request generator to ensure you are creating a valid request: The generated request can be used like any other http.Request object:

Package route53recoverycontrolconfig provides the API client, operations, and parameter types for AWS Route53 Recovery Control Config. Recovery Control Configuration API Reference for Amazon Route 53 Application Recovery Controller

This is inspired by Julien Schmidt's httprouter, in that it uses a patricia tree, but the implementation is rather different. Specifically, the routing rules are relaxed so that a single path segment may be a wildcard in one route and a static token in another. This gives a nice combination of high performance with a lot of convenience in designing the routing patterns.

Package mux provides functions to trace the gorilla/mux package (https://github.com/gorilla/mux). Currently only the routing of a received message can be instrumented. To do it, use the Middleware function.

Package netbug provides an http.Handler for executing the various profilers and debug tools in the Go standard library. netbug provides some advantages over the /net/http/pprof and /runtime/pprof packages: The simplest integration of netbug looks like: You can then access the index page via GET /myroute/ The netbug.RegisterAuthHandler function lets you register the handler on your http.ServeMux and add some simple authentication, in the form of a URL parameter: You can then access the index page via: The package also provides access to the handlers directly, for when you want to, say, wrap them in your own logic. Just be sure that when you use the handlers that netbug provides, you take care to use `http.StripPrefix` to strip the route you registered the handler on. This is because the handlers' logic expect them to be registered on "/". As you would expect, netbug works the same way with the go profiler tool as /net/http/pprof does. To run a 30 second CPU profile on your service for example:

Package echo provides functions to trace the labstack/echo package (https://github.com/labstack/echo). Currently only the routing of a received message can be instrumented. To do so, use the Middleware function.

Package dht implements a distributed hash table that satisfies the ipfs routing interface. This DHT is modeled after kademlia with S/Kademlia modifications.

Package 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: Let's start registering a couple of URL paths and handlers: 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. 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: Groups can be used inside patterns, as long as they are non-capturing (?:re). For example: The names are used to create a map of route variables which can be retrieved calling mux.Vars(): And this is all you need to know about the basic usage. More advanced options are explained below. Routes can also be restricted to a domain or subdomain. Just define a host pattern to be matched. They can also have variables: There are several other matchers that can be added. To match path prefixes: ...or HTTP methods: ...or URL schemes: ...or header values: ...or query values: ...or to use a custom matcher function: ...and finally, it is possible to combine several matchers in a single route: 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". 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: Then register routes in the subrouter: 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. 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. There's one more thing about subroutes. When a subrouter has a path prefix, the inner routes use it as base for their paths: Note that the path provided to PathPrefix() represents a "wildcard": calling PathPrefix("/static/").Handler(...) means that the handler will be passed any request that matches "/static/*". This makes it easy to serve static files with mux: Now let's see how to build registered URLs. 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: 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: ...and the result will be a url.URL with the following path: This also works for host and query value variables: 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. 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: use the methods URLHost() or URLPath() instead. For the previous route, we would do: And if you use subrouters, host and path defined separately can be built as well: