Open stmeissner opened 1 year ago
It looks like the RAML validator has issues when traits are used at the wrong place in the API spec. When defining this trait for a HTTP method header:
traits: right-header: headers: Accept: displayName: Accept Header type: string description: Accept Header required: true pattern: ^application/json$ default: application/json
and using it at a wrong place in the API spec (the header must be on the method):
/{identifier}: uriParameters: identifier: displayName: DataSource Identifier type: string description: The data source identifier. is: - right-header get: ...
The RAML validator does not complain.
When I model the same explicitly without the trait:
/{identifier}: uriParameters: identifier: displayName: DataSource Identifier type: string description: The data source identifier. headers: Accept: displayName: Accept Header type: string description: Accept Header required: true pattern: ^application/json$ default: application/json get: ...
the RAML validator throws an error as expected.
The RAML validator throws an error when using the trait at a place where its content is not compliant to the RAML standard.
It looks like the RAML validator has issues when traits are used at the wrong place in the API spec. When defining this trait for a HTTP method header:
and using it at a wrong place in the API spec (the header must be on the method):
Actual behavior
The RAML validator does not complain.
When I model the same explicitly without the trait:
the RAML validator throws an error as expected.
Expected behavior
The RAML validator throws an error when using the trait at a place where its content is not compliant to the RAML standard.