Behavioral headers enable you to change the behavior of the mocking service. There are some keys and values which you must pass in the headers to test the expected behavior of the mocking service.
Mocking Service: The API mocking service enables you to simulate the behavior of an API specification. The mocking service provides a test link to an API. The mocking service returns the responses (both HTTP status codes and example payloads) that are defined in your API specification and are valuable for testing or for simply exploring how your API behaves.
When you add an endpoint to your API specification, API Designer automatically generates a link to the API that you can use in a browser. You can also enable a public link that can be shared with users outside of the Anypoint Platform.
To test Behavioral Headers, we need the RAML specification and its Mocking Service URL. So, using the sample RAML as below:
Let us now go through some of the Behavioral headers:
- MS2-Delay: MS2-Delay indicates how many milliseconds the request should take to answer. You might want to use this header to simulate load on your server or latency in a network.
You can specify a value for this header is an integer or as a range of integers. If you specify a range, the value must have the form min-max. For example, given the value 500-1000, the request will take a random time between 500 and 1000 milliseconds.
Note – It is possible for the delay to be longer than a single integer value or the high end of a range, depending on the latency of your network.
The MS2-Delay takes a maximum value of 10000 milliseconds (ms), and follows this behavior:
If the value is set to less than 10000 ms, the mocking service adds a delay of ~5000 ms. If the value is set to greater than 10000 ms, the mocking service adds a delay of ~10000 ms. For Examples:
* If the value is set to a range of 5000 – 9000 ms, the mocking service adds a delay of ~5000 – ~9000 ms.
* If the value is set to a range of 9000 – 20000 ms, the mocking service adds a delay of ~9000 – ~10000 ms.
* If the value is set to a range of 20000 – 30000 ms, the mocking service returns this error message.
2. MS2-Example: The MS2-Example header enables you to choose a specific response example if your endpoint defines more than one example for a single status code. Using MS2-Example, you can specify multiple examples within a response. This example shows three examples for the status code 200:
Here, the possible values of the header would be one, two, and three.
Sending the value one as part of the request would return the payload something and 30.
Sending a value other than one, two, or three would return an error message.
3. MS2-Error-Level: MS2-Error-Level indicates which range of error status codes the mocking service is restricted to using. You can specify one of the following values:
a. REQUEST_ONLY: The mocking service uses only 4XX codes.
b. SERVER_ONLY: The mocking service uses only 5XX codes.
c. ALL: The mocking service can use both 4XX and 5XX codes.
Note: These Values are case-sensitive. The default value is ALL.
4. MS2-Error-Rate: MS2-Error-Rate indicates the probability of getting an error status code as a response. The value for this header must be a decimal between 0 and 1. This header works together with MS2-Status-Code, MS2-Error-Level, or both at the same time.
5. MS2-Randomize: When MS2-Randomize is set to true, the mocking service auto-generates a payload response if no example is defined for the response.
If you did not provide an example, but you used the header MS2-Randomize, set to true, with the mocking service, the payload of the returned message would contain an example with random values that matched the data types, as follow:
{
“id”: 97380,
“name”: “SeThI”
}
6. MS2-Status-Code: MS2-Status-Code specifies the status code or codes that the mocking service can choose from for the return message. This header behaves as a filter on the list of status codes that are defined for a method. For example, suppose a method has several non-error status codes defined; if you wanted the mocking service to respond with only one of those status codes, you would specify it with this header.
If you use this header together with MS2-Error-Rate, you must specify both a non-error status code and an error status code. Separate the two status codes with a comma. For example, you might want the mocking service to return a 201 message if there is no error, or a 401-status code if there is an error; in this case, you would specify 201, 401 for the value.
7. MS2-Status-Code-Selection: By default, when the mocking service responds to a request, it chooses the minimum status code that is defined for the corresponding method. For example, if you make a POST request to an endpoint that defines responses for status codes 201, 400, 409, and 500, by default the mocking service sends the response message that is defined for the 201-status code. With the MS2-Status-Code-Selection header, you can change this default behavior or the mocking service.
The possible values of MS2-Status-Code-Selection are:
FIRST: The mocking service sorts the list of status codes in ascending numeric order and returns the lowest status code. For example, if the specification defines the status codes for a POST method in the order 500, 409, 400, 200, the mocking service returns the response for the 200-status code.
RANDOM: The mocking service randomly selects one of the status codes to return. For example, if the specification defines the status codes for a POST method 500, 409, 400, 200, the mocking service returns the response for any one of them.
8. MS2-Strict-Model-Validation: This header can be helpful when you are simulating calls to an API with a specification that was written before API Designer switched to its stricter parser on January 10, 2019.
When you set this header to false, you can use the mocking service even when the API specification contains errors.
When you set this header to true, the mocking service validates the specification before responding. If there is an error in the specification, the mocking service fails with that error. Otherwise, the mocking service works as usual.
References:
- https://www.mulesoft.com/exchange/org.mule.examples/mocking-service-2-api/minor/1.1/pages/Behavioral%20Headers/
- https://docs.mulesoft.com/design-center/apid-behavioral-headers
- https://github.com/mulesoft/docs-design-center/blob/latest/modules/ROOT/pages/apid-behavioral-headers.adoc
- https://beta.docs.stgx.mulesoft.com/beta-mule-sdk/design-center/apid-behavioral-headers
