Routing Changes in 0.8

Many of the namespaces used in routing had internal functions not marked as private; these have been made private.

Previously, it was assumed that there was a single specification for all routes; in trivial examples this might be a set (which, via the RouteSpecification protocol) is interpreted as a call to table-routes).

Other applications might invoke table/table-routes directly.

In either case, this single value is provided as the ::http/routes key of the service map.

A single set of routes is now considered a special case; the more general case is that multiple sets of routes will be mixed together to form the overall routing table.

The return type of table-routes/routes, and the other built-in route definitions (terse-routes and expand-verbose-routes) have been changed; previously they returned a seq of route maps; they now return a RoutingFragment (essentially, a wrapper around a seq of route maps).

Likewise, the routes-from macro now accepts a variable number of expressions.

The ExpandableRoutes protocol is now used to convert an arbitrary data structure to a RoutingFragment (not a seq of expanded routes); these fragments are then combined, by expand-routes, into the full routing table.

Previously, expand-routes only accepted a single value; it now accepts one or more RoutingFragments.

The RouterSpecification protocol was used to choose a different strategy based on whether the routing table was an actual value, or a function that returns a value; the protocol has been removed as there were only ever two implementations.

The Router protocol, and the containing io.pedestal.http.route.router namespace, have been removed; instead, each router contructor simply returns a router function.

The contract has changed slightly; on a successful route, the router function returns a tuple of two values: