app/routers
. Router
class with a router specification, and exporting the extended class from its router module. Below is an example router named message
with an empty specification.specification
property of the router, and begin with a forward slash (/
). The example below updates our message
router with the single path /messages
.GET
, POST
, PUT
, and DELETE
. The verb notifies the server (i.e., the application in our case) of what action to execute when a client sends a request to the corresponding path. In our current specification, we have defined a path, but we have not defined what HTTP verb on the path is active, and what action the HTTP verb executes. We call this a reaction.message
router to support creating messages.POST /messages
. When a client sends this HTTP request to the application, it will execute the create
action on the message controller
. We will visit how to implement this action later in the guide. For now, let's focus on the route definition in the message
router.message
router, the key for nested objects of a path is a HTTP verb. In this example, the HTTP verb is post
. action
property in the hash associated with the corresponding HTTP verb. In our example above, the controller action is [email protected]
. This means that POST /messages
is going to invoke the create
action on the message
controller.__invoke()
. When binding a path to the default action of a controller, you do not need to provide the action name. Instead, just specify the controller name in the action
property. The following example illustrates binding the path to the default action for the message
controller.view
property instead of the action
property for the corresponding route.GET /messages
route will use the messages
view to display the messages to the users./messages
is a static route. But, /messages/1
and messages/2
are dynamic routes. This is because the part of the path after /messages
is can change depending what context the client is hoping to access.:
). For example, :messageId
is a parameter./messages/:messageId
is dynamic route. Likewise, the :messageId
parameter will be accessible on req.params
as req.params.messageId
./messages
. This is call a nested routed. Nested routes is Blueprint's method for allowing you to extend an existing route with a child route, and reduce problems related to defining related routes. The dynamic route from above is the same as this one./messages
definition. This means that allow properties, such as policies and Express middleware, of the /messages
route will also apply to the /messages/:messageId
route./v1
prefix. The simple approach is to just nest all paths in a router under /v1
. This suffices, but it also means you have to do the same for each routers. Likewise, changing the name of the prefix means you have to update each router definition. /v1
, but place all routers under the v1/
directory. For example:message
, comment
, and like
router will be prefixed with /v1
. For example, /v1/messages
and /v1/messages/:messageId
are valid routes./v1
vs /v2
).use
keyword to add middleware to a route. For example, here we are adding the CORS middleware to our route.use
property takes an Express middleware function with the signature function (req, res, next)
, or an array of Express middleware functions.mount()
method. Here is an example of mounting a router to the /images
path.images
router from the blueprint-images-cdn
Blueprint module. If you do not provide a module name (i.e., only use images
), then the router is assumed to be part of the application.