Routing
Routing determines how an application responds to a client request to a particular endpoint, which is a path and a specific HTTP method (eg. GET, POST).
Route composition
As we know - every API requires composable routing. Lets assume that we have a separate User feature where its API endpoints respond to GET and POST methods on /user
path.
Since Marble.js. v2.0, you can choose between two ways of defining HTTP routes - using EffectFactory
or using r.pipe
operators. In this example we will stick to the second, newer way, which has a more functional flavor and is more composable.
r.pipe
is an indexed monad builder used for collecting information about Marble REST route details, like: path, request method type, middlewares and connected Effect.
Defined HttpEffects can be grouped together using combineRoutes
function, which combines routing for a prefixed path passed as a first argument. Exported group of Effects can be combined with other Effects like in the example below.
As you can see, the previously defined routes can be combined together, so as a result the routing is built in a much more structured way. If we analyze the above example, the routing will be mapped to the following routing table.
There are some cases where there is a need to compose a bunch of middlewares before grouped routes, e.g. to authenticate requests only for a selected group of endpoints. Instead of composing middlewares using use operator for each route separately, you can compose them via the extended second parameter incombineRoutes()
function.
Body parameters
Marble.js doesn't come with a built-in mechanism for parsing POST, PUT and PATCH request bodies. In order to get the parsed request body you can use dedicated @marblejs/middleware-body package. A new req.body
object containing the parsed data will be populated on the request object after the middleware, or undefined if there was no body to parse, the Content-Type
was not matched, or an error occurred. To learn more about body parsing middleware visit the @marblejs/middleware-body API specification.
All properties and values in req.body
object are untrusted and should be validated before usage.
By design, the req.body, req.params, req.query
are of type unknown
. In order to work with decoded values you should validate them before (e.g. using dedicated validator middleware) or explictly assert attributes to the given type. We highly recommend to use the @marblejs/middlware-io package which allows you to properly infer the type of validated properties.
URL parameters
The combineRoutes
function and the matchPath
allows you to define parameters in the path argument. All parameters are defined by the syntax with a colon prefix.
Decoded path parameters are placed in the req.params
property. If there are no decoded URL parameters then the property contains an empty object. For the above example and route /bob/12
the req.params
object will contain the following properties:
For parsing and decoding URL parameters, Marble.js makes use of path-to-regexp
library.
All properties and values in req.params
object are untrusted and should be validated before usage.
You should validate incoming URL params using dedicated requestValidator$ middleware.
Path parameters can be suffixed with an asterisk (*
) to denote a zero or more parameter matches. The code snippet below shows an example use case of a "zero-or-more" parameter. For example, it can be useful for defining routing for static assets.
Query parameters
Except intercepting URL params, the routing is able to parse query parameters provided in path string. All decoded query parameters are located inside req.query
property. If there are no decoded query parameters then the property contains an empty object. For parisng and decoding query parameters, Marble.js makes use of qs
libray.
Example 1:
Example 2:
All properties and values in req.query
object are untrusted and should be validated before usage.
You should validate incoming req.query
parameters using dedicated requestValidator$ middleware.
Last updated