GET
, DELETE
, POST
, and PUT
) and a path (e.g., /a/b/c
). In the super-rentals example, there is the single route GET /api/rentals
. Because we want our Blueprint application to serve as the API service for the super-rentals example, we need our application to define the same route as expect by the EmberJS application.rental
. There are several approaches we can use when defining a router, which depends on how much reuse we want across a routes paths. The first approach is we can define all routes in a single router with nested definitions. For example:super-rentals
example has a single route GET /api/rentals
. Let's assume that if we want to define other routes, they will have the base path /api
. We therefore want to define our routers in the subdirectory named api
. Let's start with the single router named rental
./rentals
. We do not include /api
in the path definition because this router is located in the api
subdirectory. This means that routes defined in routers located in the api
subdirectory will be prefixed with /api
. If we placed this same router in the subdirectory named v1
, which is a subdirectory of api
, then the base path will be /api/v1
./api/rentals
. As previously discussed, the HTTP verb we need to respond to is the GET
verb. We already have implemented the action that returns a list of rentals. Let's bind this path to that specific action.