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.super-rental application. There is minimal work needed to replace mirage with this Blueprint application. The main approach is to leverage the power of adapters and serializers in ember-data, which allows an EmberJS application to integrate with virtually any backend api service, including Blueprint.super-rental application has configured ember-data to handle JSON-API by default. We just have to instruct the application to retrieve the data from the Blueprint application instead of from mirage. We do this by implementing an application adapter that defines where the data is located.