A set of rules for Spectral that allows linting OpenAPI and AsyncAPI spec for Microcks conventions
npm install @microcks/spectral-rulesetA set of rules for Spectral that allows linting OpenAPI and AsyncAPI spec for Microcks conventions.
Microcks conventions for OpenAPI and AsyncAPI specification files can be sometime a little boring to apply and debug. This set of rules allows you to use your favorite linter to detect if some of the conventions are missing or are incomplete so that Microcks will be able to import comprehensive mocks š
This ruleset is initially targeting the Spectral linter but we also added a compatibility layer for Vacuum. As this is not our primary focus, we'll see what it means to support this layer in the long-term...
Latest released version is 0.0.6.
Current development version is 0.0.7-SNAPSHOT.
#### Fossa license and security scans
#### OpenSSF best practices on Microcks core
* Documentation
* Microcks Community and community meeting
* Join us on Discord, on GitHub Discussions or CNCF Slack #microcks channel
To get involved with our community, please make sure you are familiar with the project's Code of Conduct.
| This ruleset | Spectral Version | Vaccum Version |
|--------------|------------------|----------------|
| <= 0.0.5 | 6.11.1 and + | 0.9.16 and + |
| >= 0.0.6 | 6.14.0 and + | 0.9.16 and + |
Developers wanting to pull the ruleset can just install the package using yarn or npm and reference the module name in extends:
``yaml`
extends:
- "@microcks/spectral-ruleset"
Locking a ruleset on a given version is possible through package.json:
`json`
{
"dependencies": {
"@microcks/spectral-ruleset": "0.0.5"
}
}
If you use Spectral in a browser or don't want to install the package, you can also reference that package through the use of CDNs for npm repositories, such as unpkg.com. You can then put directly in your own rules our .spectral.yaml file, the following directive:
`yaml`
extends:
- "https://unpkg.com/@microcks/spectral-ruleset@0.0.5"
To illustrate the results of applying the ruleset, let's have a look at the Weather Forecast API OpenAPI specification. Eventhough everything looks nice at a first look, some issues will prevent Microcks to collect and build comprhensive mocks from the spec elements:
1. L39: unknown is an expected response (see L96) but no value has been defined for this parameter. Microcks will not be able to associate response with parameter value, apiKey
2. L54: parameter is required but no examples are provided. The mock will not be representative of expected API behavior,temp
3. L95: has been defined as a number in the schema but we provided a string. The mock will not be consistent with the API types definition,SetForecast
3. L115: the operation request define an example called north but no response has this name. Microcks will not be able to associate response with body value, SetForecast
4. L125: the operation defines no examples for both the response. Microcks will not be able to guess mock values for these one,DeleteForecast
5. L140: the operation defines an example for a region center and there's no response for this region. Microcks will not be able to find a suitable response,DeleteForecast
6. L146: the operation is a no-content response so it uses x-microcks-refs to tell to what response elements it should bind the response. However, the center-south value has not be defined as a valid parameter value... Microcks will not be able to bind to a matching request,team
7. L18: label used in x-microcks extension is not well-formed as it should just be a string, delay
8. L30: information used in x-microcks-operation extension is not well-formed as it must be an integer.
Debugging everything by hand can be tedious... So here's how to detect those issues and get some hints on what's going wrong. āØ
We'll use the microcks-rules.yaml ruleset definition file here. If you followed the above instruction on how to use it via unpkg, you don't need to include the -r microcks-rules.yaml part of the command:
`shell
$ spectral --version
6.11.1
$ spectral lint -r microcks-rules.yaml resources/weather-forecast-openapi-bad.yaml
/Users/laurent/Development/github/microcks-spectral-ruleset/resources/weather-forecast-openapi-bad.yaml
18:12 warning microcks-info-extension-valid x-microcks extension must be valid info.x-microcks.labels.team
30:16 warning microcks-operation-extension-valid x-microcks-operation extension must be valid paths./forecast/{region}.get.x-microcks-operation.delay
49:11 warning microcks-examples-in-required-parameter Required param must have examples paths./forecast/{region}.get.parameters[1]
55:17 warning microcks-examples-fragments-to-complete-mocks šØ Response example 'unknown' is incomplete, it has no matching input example. It requires at least one requestBody or parameter example with same name to be considered as valid mock for Microcks. paths./forecast/{region}.get.responses
95:27 error oas3-valid-media-example "temp" property type must be number paths./forecast/{region}.get.responses[200].content.application/json.examples.south.value.temp
121:17 warning microcks-examples-fragments-to-complete-mocks ā¹ļø Request body example 'north' is not used in any response. It requires to have a matching response example or a x-microcks-refs to be considered as valid mock for Microcks. paths./forecast/{region}.put.responses
125:30 warning microcks-examples-in-response-content Response with content must have examples paths./forecast/{region}.put.responses[200].content.application/json
142:17 warning microcks-examples-fragments-to-complete-mocks š Response has x-microcks-refs 'center-south' but it doesn't match input example. It requires at least one requestBody or parameter example with same name to be considered as valid mock for Microcks. paths./forecast/{region}.delete.responses
142:17 warning microcks-examples-fragments-to-complete-mocks ā¹ļø Path parameter example 'center' is not used in any response. It requires to have a matching response example or a x-microcks-refs to be considered as valid mock for Microcks. paths./forecast/{region}.delete.responses
ā 9 problems (1 error, 8 warnings, 0 infos, 0 hints)
`
If you'd like a more human-readable output of Microcks hints for a complete document, you can set the MICROCKS_HINTS environment variable to true when running spectral:
`shell
$ MICROCKS_HINTS=true spectral lint -r microcks-rules.yaml resources/weather-forecast-openapi-bad.yaml
šØ Response example 'unknown' for 'paths./forecast/{region}.get' is incomplete, it has no matching input example.
It requires at least one requestBody or parameter example with same name to be considered as valid mock for Microcks.
ā¹ļø Request body example 'north' for 'paths./forecast/{region}.put' is not used in any response.
It requires to have a matching response example or a x-microcks-refs to be considered as valid mock for Microcks.
š Response has x-microcks-refs 'center-south' for 'paths./forecast/{region}.delete' but it doesn't match input example.
It requires at least one requestBody or parameter example with same name to be considered as valid mock for Microcks.
ā¹ļø Path parameter example 'center' for 'paths./forecast/{region}.delete' is not used in any response.
It requires to have a matching response example or a x-microcks-refs to be considered as valid mock for Microcks.
/Users/laurent/Development/github/microcks-spectral-ruleset/resources/weather-forecast-openapi-bad.yaml
18:12 warning microcks-info-extension-valid x-microcks extension must be valid info.x-microcks.labels.team
[...]
`
We'll use the microcks-vacuum-rules.yaml ruleset definition file here:
`shell
$ vacuum lint -r microcks-vacuum-rules.yaml -f ./functions resources/weather-forecast-openapi-bad.yaml -d
āāā āāā āāāāāā āāāāāāāāāā āāāāāā āāāāāāā āāāā
āāā āāāāāāāāāāāāāāāāāāāāāā āāāāāā āāāāāāāā āāāāā
āāā āāāāāāāāāāāāāā āāā āāāāāā āāāāāāāāāāāāāā
āāāā āāāāāāāāāāāāāāā āāā āāāāāā āāāāāāāāāāāāāā
āāāāāāā āāā āāāāāāāāāāāāāāāāāāāāāāāāāāāāāāāā āāā āāā
āāāāā āāā āāā āāāāāāā āāāāāāā āāāāāāā āāā āāā
version: 0.9.16 | compiled: Thu, 09 May 2024 19:57:46 UTC
š https://quobix.com/vacuum | https://github.com/daveshanley/vacuum
INFO Located custom javascript function: 'aas-verify-mocks'
ERROR Failed to load function 'aas-verify-mocks': SyntaxError: SyntaxError: (anonymous): Line 16:1 Unexpected reserved word (and 8 more errors)
INFO Located custom javascript function: 'oas-verify-mocks-vacuum'
INFO Located custom javascript function: 'oas-verify-mocks'
ERROR Failed to load function 'oas-verify-mocks': SyntaxError: SyntaxError: (anonymous): Line 16:1 Unexpected reserved word (and 20 more errors)
INFO Loaded 3 custom function(s) successfully.
INFO Linting file 'resources/weather-forecast-openapi-bad.yaml' against 7 rules: https://quobix.com/vacuum/rulesets/no-rules
2024/05/21 14:17:56
2024/05/21 14:17:56 šØ Response example 'unknown' for 'GetForecast' is incomplete, it has no matching input example.
2024/05/21 14:17:56 It requires at least one requestBody or parameter example with same name to be considered as valid mock for Microcks.
2024/05/21 14:17:56
2024/05/21 14:17:56 ā¹ļø Request body example 'north' for 'SetForecast' is not used in any response.
2024/05/21 14:17:56 It requires to have a matching response example or a x-microcks-refs to be considered as valid mock for Microcks.
2024/05/21 14:17:56
2024/05/21 14:17:56 š Response has x-microcks-refs 'center-south' for 'DeleteForecast' but it doesn't match input example.
2024/05/21 14:17:56 It requires at least one requestBody or parameter example with same name to be considered as valid mock for Microcks.
2024/05/21 14:17:56
2024/05/21 14:17:56 ā¹ļø Path parameter example 'center' for 'DeleteForecast' is not used in any response.
2024/05/21 14:17:56 It requires to have a matching response example or a x-microcks-refs to be considered as valid mock for Microcks.
/Users/laurent/Development/github/microcks-spectral-ruleset/resources/weather-forecast-openapi-bad.yaml
-------------------------------------------------------------------------------------------------------
Location | Severity | Message | Rule | Category | Path
resources/weather-forecast-openapi-bad.yaml:15:5 | warning | x-microcks extension must be valid | microcks-info-extension-valid | Validation | $.info[0]
resources/weather-forecast-openapi-bad.yaml:24:7 | warning | Response example 'unknown' is incomplete, it has no matching input example | microcks-examples-fragments-to-complete-mocks | Validation | $.paths..
resources/weather-forecast-openapi-bad.yaml:30:9 | warning | x-microcks-operation extension must be valid | microcks-operation-extension-valid | Validation | $.paths..[0]
resources/weather-forecast-openapi-bad.yaml:49:11 | info | Parameters should have examples | microcks-examples-in-parameter | Validation | $..parameters[0][1]
resources/weather-forecast-openapi-bad.yaml:92:17 | warning | expected number, but got string | oas3-valid-schema-example | Examples | $.paths['/forecast/{region}'].get.responses['200'].content'...
resources/weather-forecast-openapi-bad.yaml:108:7 | warning | Request body example 'north' is not used in any response | microcks-examples-fragments-to-complete-mocks | Validation | $.paths..
resources/weather-forecast-openapi-bad.yaml:126:15 | warning | Response with content must have examples | microcks-examples-in-response-content | Validation | $.paths..responses..content.*
resources/weather-forecast-openapi-bad.yaml:129:7 | warning | Response has x-microcks-refs 'center-south' but it doesn't match input example | microcks-examples-fragments-to-complete-mocks | Validation | $.paths..
resources/weather-forecast-openapi-bad.yaml:129:7 | warning | Path parameter example 'center' is not used in any response | microcks-examples-fragments-to-complete-mocks | Validation | $.paths..
Category | Errors | Warnings | Info
Validation | 0 | 7 | 1
Examples | 0 | 1 | 0
Linting passed, but with 8 warnings and 1 informs
`
#### microcks-info-extension-valid
This rule will check that info.x-microcks is well-formed according to its schema information.
x-microcks OpenAPI and AsyncAPI extension allows you to provide labels for organizing your API and Services in Microcks. Labels are simple key/value pairs where keys and values are string.
Severity: warn
#### microcks-operation-extension-valid
This rule will check that x-microcks-operation provided for operation is well-formed according to its schema information.
x-microcks-operation OpenAPI and AsyncAPI extension allows you to provide custom dispatching rules and delays for your mocks. We'll check that attributes are known from Microcks to guarantee their application.
Severity: warn
#### Reused external rules
The Microcks ruleset imports the oas3-valid-media-example and oas3-valid-schema-example rules from the [Spectral OpenAPI Rules.
These rules check that the examples definitions are conformant to the schema definition with the API specification. Having incorrect values or types will not prevent Microcks to produce mocks but these ones will be totally useless for people wanted to have a high-fidelity simulation of the API.
Severity: error
#### microcks-examples-in-required-parameter
This rule will ask you to provide named examples for parameters marqued as required.
Putting named examples in parameters allows you to explicit values of parameters depending on different situation and then to later bind them with corresponding request body or response. This provide a better overview of the expected behavior of your API for people who will discover it. Not providing these examples prevents Microcks from producing correct and representative mocks.
Severity: warn
#### microcks-examples-in-optional-parameter
This rule will recommend you to provide named examples for parameters marqued as optional.
Putting named examples in parameters allows you to explicit values of parameters depending on different situation and then to later bind them with corresponding request body or response. This provide a better overview of the expected behavior of your API for people who will discover it.
Severity: info
#### microcks-examples-in-request-content
This rule will ask you to provide named examples within requestBody.content.*.
Putting named examples in request content allows you to explicit payload depending on different situation and then to later bind them with corresponding response. This provide a better overview of the expected behavior of your API for people who will discover it. Not providing these examples prevents Microcks from producing mocks.
Severity: warn
#### microcks-examples-in-response-content
This rule will ask you to provide named examples within responses..content..
Putting named examples in response content allows you to explicit payload depending on different situation and then to later bind them with corresponding request body or parameter values. This provide a better overview of the expected behavior of your API for people who will discover it. Not providing these examples prevents Microcks from producing mocks.
Severity: warn
#### microcks-examples-fragments-to-complete-mocks
This rule will check the coherence of different response, request and parameter examples to detect incomplete combination.
Severity: warn
#### Reused external rules
The Microcks ruleset imports the asyncapi-message-examples from the Spectral AsyncAPI Rules.
This rule checks that the examples definitions are conformant to the schema definition with the API specification. Having incorrect values or types will not prevent Microcks to produce mocks but these ones will be totally useless for people wanted to have a high-fidelity simulation of the API.
Severity: error
#### microcks-aas-examples-in-message
This rule will ask you to provide named examples within $.channels.*.[publish,subscribe].message.
Putting named examples in message allows you to explicit payload depending on different situation and then optionally to later bind them with corresponding parameter values. This provide a better overview of the expected behavior of your API for people who will discover it. Not providing these examples prevents Microcks from producing mocks.
Severity: warn
#### microcks-aas-examples-in-parameter
This rule will ask you to provide named examples within $.channels..parameters..schema.
Putting named examples in channel parameters allows you to explicit values of parameters depending on different situation and then to later bind them with corresponding message content. This provide a better overview of the expected behavior of your API for people who will discover it. Not providing these examples prevents Microcks from producing correct and representative mocks.
Severity: warn
#### microcks-aas-examples-fragments-to-complete-mocks
This rule will check the coherence of different messages and parameter examples to detect incomplete combination.
Severity: warn`