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:
...
Actual behavior
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.
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.
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.