Create global rules for your routes

When creating an API mock, you often need to apply the same rules to all your endpoints. It also makes your mock more consistent and easier to maintain. For example, you may want to check that all your requests contain an Authorization header or that they all contain a specific property in their body. In mockoon, you can easily create routes that will apply rules to all your endpoints and server specific responses, like a 401 Unauthorized. This tutorial will show you how to do it through an example.

Creating global rules in Mockoon requires the use of different features:

• The response's fallback mode.
• Wildcard routes
• Response rules

In this tutorial, we will create a mock API with a simple GET route and a global route that will check that all the requests contain an Authorization header and return a 401 Unauthorized error if that's not the case.

 1. Create a route to protect

Starting with an empty environment, create a new route and set its path to /protected and its method to GET:

You can keep the status code to 200 and add a simple JSON response body:

Copy
{
  "response": "success"
}

 2. Create a wildcard route

To create a global route, you first need to create a new HTTP route that will match all the endpoints you want to protect, both with its path and method(s). To do so, create a new route, set its path to *, which will match any path, and select "All methods" in the method dropdown:

We could also set its path to /protected and its method to GET to match our previous route, but it would only protect this specific route and not all the others.

Important point: you need to move the wildcard route above the GET /protected route, so it can be evaluated first and catch all the requests. You can create it first or move it up in the routes list with a drag and drop.

 3. setup the response and rule

The second step is to set up one or more responses with rules on this wildcard route. We will create a rule checking that the request contains an Authorization header and return a 401 error if it's not present.

 3a. Set the status code and body

Modify the existing response by setting the status code to 401:

You can also add a simple JSON response body returning an error:

Copy
{
  "error": "Unauthorized"
}

 3b. Create a new rule

The second step is to add a new rule to this response by navigating to the "Rules" tab in the response view and clicking the "Add rule" button. In the newly added rule, select the "Header" rule type. Then, set the "Header name" to Authorization and the operator to null:

 4. Activate the fallback mode

Once your route is created and your responses customized, activate the fallback mode on your wildcard route by clicking on the "fallback" icon next to the response list:

The fallback mode will automatically pass the request to the next route, here GET /protected, when none of the wildcard route rules match.

 5. Test your mock

Our setup is complete, and we can now test our mock by making two requests to our GET /protected route, one without and one with an Authorization header.

First, start your environment by clicking on the green "play" button at the top:

Then, open a terminal and make a request without the Authorization header using curl:

Copy
curl -i http://localhost:3000/protected

You should get a 401 Unauthorized error with our "Unauthorized" response body:

Copy
$ curl -i http://localhost:3000/protected
HTTP/1.1 401 Unauthorized
[...]
{
  "error": "Unauthorized"
}

Now, make a second request with a fake Authorization header:

Copy
 curl -i http://localhost:3000/protected -H "Authorization: xxxx"

You should get a 200 status code with our "Success" response body:

Copy
$ curl -i http://localhost:3000/protected -H "Authorization: xxxx"
HTTP/1.1 200 OK
[...]
{
  "response": "success"
}