A Conceptual Model
One way to think about it is that Routes & Controllers are both controllers in the MVC nomenclature. Controllers are concerned with controlling the connection between Models and their display, and getting data into and out of them, and Routes are concerned with controlling the connection between Models, between Models and the application, and between Models and their persistence layer.
Application: the granddaddy model
In this view Application is the granddaddy model (and it is always there: even if you don't explicitly refer to it there is an ApplicationRoute and ApplicationController being anonymously created). So naturally, routes control the connection between the Application and other Models.
The Most Common Setup
For a given model, there will typically be (as a basic starting point) two Routes and two Controllers. One Route manages the retrieval of a collection of the Model, and a corresponding Controller connects that collection to a view of the collection, and another Route manages the choosing of a single instance of the Model, binding it to a controller that manages its connection to a view.
Who handles Actions?
Views, Routes and Controllers can all intercept and handle actions. They each have a special ability that the others do not.
The Controller Special Ability
The special ability of Controllers is that they know about the specific instance or collection of a Model that the action concerns. If an action comes to a controller it is generally originating in a view element concerned with that controller's model. So, actions defined on controllers should do something with a model or model collection. If an action does not care about a model/collection, it probably belongs on a Route.
The Route Special Ability
The special ability of Routes is that they know the hierarchy into which models/collections have been organized. This means that they can do things involved with navigation more naturally than controllers can.
The View Special Ability
The special ability of Views is that they know about the interface, and events animation etc.
Handling Actions with multiple Handlers
Although it is not necessary, I often split an action into two (or even three) handlers, often with the same name. In the case of two, one handler lives on a Controller, and does the part of the action concerned with selecting, querying, or otherwise talking to a Model. The other handler lives on a route and is concerned with the navigational part of the action. When actions are split up this way, you find your app becomes easier to refactor, and you have to do less gymnastics to accommodate "weirdness" in the html structure of your views (in particular for negative actions like cancel or deselect).
Sometimes a third handler lives on the View and does jquery-ish things or css animation. In each case when a component has done their part of an action, it uses send to forward the action to the next component that should deal with it. Typically that means View->Controller->Route.
Summary
So to sum up, Routes should focus on managing the retrieval of models and the connections between them and between them and your app, handling the parts of actions concerned with navigation and app state. Controllers should focus on managing the connection of models with html view elements, handling the parts of actions concerned with choosing/unchoosing/modifying a particular model or model collection (note: choosing is usually switching to a new route, and handled by a Route. But sometimes controllers handle non-route choices, like setting an attribute on one model by choosing an item from a list of another model). Views should handle the parts of actions concerned with changing the html they represent, ie, animation, css changes that reflect state, etc.
