You can use the mock
policy to create mock responses when a consumer calls one of your services.
This means you do not have to provide a functional backend as soon as you create your API, giving you more time to think about your API contract.
You can think of the policy as a contract-first approach — you are able to create a fully-functional API without needing to write a single line of code to handle consumer calls.
Internally, this policy replaces the default HTTP invoker with a mock invoker. There are no more HTTP calls between the gateway and a remote service or backend.
Note
|
The Mock policy will not cause the other policies to be skipped, regardless of its location in the flow. |
When defining the response body content, you can use Expression Language to provide a dynamic mock response.
Note that you don’t need to provide the Content-Type
header, since the Mock policy can automatically detect the
content type.
<user id="{#request.paths[3]}">
<firstname>{#properties['firstname_' + #request.paths[3]]}</firstname>
<lastname>{#properties['lastname_' + #request.paths[3]]}</lastname>
<age>{(T(java.lang.Math).random() * 60).intValue()}</age>
<createdAt>{(new java.util.Date()).getTime()}</createdAt>
</user>
You can configure the policy with the following options:
Property | Required | Description | Type | Default |
---|---|---|---|---|
status |
X |
HTTP Status Code |
integer |
|
headers |
X |
HTTP Headers |
Array of HTTP headers |
|
content |
X |
HTTP Body content |
string |
"mock": {
"status": "200",
"headers": [
{
"name": "Content-Type",
"value": "application/json"
}, {
"name": "Server",
"value": "Gravitee.io"
}
],
"content": "<user id=\"{#request.paths[3]}\">\n\t<firstname>{#properties['firstname_' + #request.paths[3]]}</firstname>\n\t<lastname>{#properties['lastname_' + #request.paths[3]]}</lastname>\n\t<age>{(T(java.lang.Math).random() * 60).intValue()}</age>\n\t<createdAt>{(new java.util.Date()).getTime()}</createdAt>\n</user>"
}