The node-mock-server supports importing swagger descriptions for an API. However, you can create mock resources manually, too.
The node-mock-server expects you to follow the path conventions below for the content of your restPath folder.
|- group
|--- #
|--- #path
|--- #path#{param}
|----- method (GET, POST, DELETE ...)
|------- mock
|--------- success.json
|--------- success.headers.json
|--------- error.json
|--------- error-401.json
|------- desc.json
|------- request_schema.json
|------- response_schema.json
See /demo/rest for an executable example.
The top level folder becomes the url path segment immediately after your API urlPath: if your urlPath is /rest/v2, then you would get a /rest/v2/group resource in your mock API for the folder structure above.
The # represents a slash in the url path of your response. In other words, the # folder above describes the responses to requests for /rest/v2/group/ (trailing slash) whereas the #path folder will become the /rest/v2/group/path resource in your API.
If you want to use dynamic path segments, you can enclose them in curly brackets, as shown above for the #path#{param} folder. The node-mock-server looks for a success response called success-1 if the requested url is /path/1, success-2 is for /path/2 etc., and success-default is for all other cases. For examples how the actual value can be used inside responses, look at the success files for products in the demo.
A path folder with # must contain one or more method folders, e.g. GET or POST which require to contain a mock directory in turn - that directory will later contain the actual API responses.
The file desc.json is optional and can be used to describe the response to a method call on a resource in more detail. Consider the sample desc.json below.
{
"desc": "Returns a list of products",
"security": [],
"protected": false,
"status": "open",
"request": {
"query": {
"parameters": [
{
"name": "query",
"required": false,
"type": "string",
"desc": "Search query"
}
]
}
},
"response": {
"statusCode": 200,
"schema": {
"type": "application/json"
}
}
}
The example above provides a descriptive string in the desc attribute and specifies expected requests and possible responses.
The files request_schema.json and response_schema.json are optional and may contain json schema definitions for your requests and responses which allow for validation.