Extole · API Governance Rules
Extole API Rules
Spectral linting rules defining API design standards and conventions for Extole.
8 Rules
error 5
warn 3
Rule Categories
error
every
operation
Rules
warn
operation-must-have-summary
Every operation must have a `summary` so renderers and SDKs have a one-line label for it.
#AllOperations
error
operation-id-must-be-camelCase-and-not-bare
`operationId` must be camelCase and must not be a bare HTTP-verb or synonym (`get`, `list`, `create`, ...). Bare verbs collide across resources and produce nonsense SDK methods.
#AllOperations.operationId
warn
operation-id-must-be-camelCase
`operationId` must be camelCase.
#AllOperations.operationId
error
operation-must-have-real-tag
Every operation must have at least one tag, and tags must be human-readable labels - never raw URL paths like `/v1/audiences`.
#AllOperations
error
operation-tag-must-not-be-url-path
Operation tags must be semantic names, never URL paths.
#AllOperations.tags[*]
error
operation-tag-must-not-contain-extention-typo
Prevent regressions of the `Extentions` typo in any rendered operation tag.
#AllOperations.tags[*]
warn
every-property-must-have-description
Schema properties should have a `description` so the rendered docs and generated SDKs are readable.
$.components.schemas[*].properties[*]
error
error-response-must-not-be-megastring
4xx/5xx responses must use the structured shape: a non-blank `description` and a JSON content entry that references the `RestExceptionResponse` schema. The legacy "code=..., message=..." megastring description is no longer allowed.
$.paths[*][get,put,post,delete,options,head,patch,trace].responses[?(@property.match(/^[45]/))].description