So far, we’ve defined a single function that handled all requests; aside from the simplest of applications, this will never do. We want to be able to structure our applications naturally, separating logically distinct functionality into different Ring handlers in potentially different namespaces, pulling them all together in just the right arrangement. We could try to pick apart request URI strings to delegate request handling to other functions; however, just as we composed our Ring handler with some middleware to augment our application, there are better ways to achieve our ends.
Very simply, routing is the selection of a handler that should be used to respond to a web request, and routes are patterns of incoming request attributes that are used to drive that selection process. Abstractly, you can easily imagine defining web applications in terms of a table of routes that correspond to particular handlers defined in various namespaces (Figure 16-1).
Figure 16-1. Pairing routes up with handlers
GET request is received for the root of the application
/), that request will be routed to the
homepage handler. When a
PUT request is received for any URI with a single segment
:id in the diagram),
that request will be routed to the
retain handler; the same goes for any
POST request to the root of the application, and
Let’s build ...