Most routing systems combine the “routing” task with the “dispatch” task. That is, they both extract the parameters and pick the controller/action. Aura.Router v2, because of its truly independent nature, only does routing. It turns out that dispatching is something that can be independent of routing, and so we have a separate Aura.Dispatcher package to handle that (although you can use any dispatching system you like).

Aura.Router v2 allows you to examine the $_SERVER values and pick a route based on them using the addServer() method. For example, if you want to match routes based on the HTTP_ACCEPT value …

$router->addRoute('json_only', '/accept/json/{id}')
  // must be of quality *, 1.0, or 0.1-0.9
  'HTTP_ACCEPT' => 'application/json(;q=(*|1.0|[0.[1-9]]))?'

Sometimes we need a params in the route path to be sequentially optional. The classic example is a blog archive organized by year, month, and day. We don’t want to have to write three routes, one for /{year}, /{year}/{month}, and /{year}/{month}/{day}, each with repeated information about the route.

In Aura.Router v2, there is a special notation similar to URI Templates that indicates sequentially optional params: {/param1,param2,param3}

We can now add REST resource routes in a single call to attachResource():

$router->attachResource('blog', '/blog');

This will add seven REST routes with appropriate names, paths, HTTP methods, and token regexes …

If you decide those routes are not to your liking, you can override the default behavior by using setResourceCallable() to pass callable of your own to create resource routes.

Via A Peek At Aura v2 -- Aura.Router.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving you codebase, all while keeping it running the whole time.