Contracts
5 pages filed under Rules › Contracts. A business rule is a condition the business imposes, with what it constrains and what happens when it is broken.
| Business rule | Severity | First line | Links |
|---|---|---|---|
| Ambiguous operation | warning | At the rung of the operation matching where a match is found, two operation notes claim the same operation imported from a contract, or one note matches several operations of its API. Nothing is attached: the finding names every candidate, the imported operation stays a separate entity with the properties of the contract only, and the other notes and operations of the API are matched as usual. The operation_id of exactly one operation in each note settles it; a note that names no API and matches several contracts of its source names its API in the api attribute. | 27 |
| API without consumer | warning | An API has no consumer, declared or inferred: no attribute, no section, no mention in another note. | 22 |
| Consumer mismatch | warning | An API declares a consumer that never cites it, or a note cites an API that does not list it. One of the two is out of date. A declared consumer is an identifier, written in full or relative to the source of the API note; a note listed under the ## Consumers section of the API note is declared too; a note cites the API when a serves link between the two was read in that note, the API's own consumers attribute and ## Consumers section being declarations rather than citations. The attribute asks for the reconciliation: an API note without it is left to the API without consumer check. | 22 |
| Operation unmatched | warning | An operation note that names an API with an imported contract, in its api attribute or through a markdown link, and that none of the three rungs of the operation matching attaches to an operation of that contract. One of two things is true: the operation disappeared from the contract and the note describes something that no longer exists, or the note is ahead of the contract and describes an operation the next version will declare. The build cannot tell which, so the finding says both, and the author decides: retire the note or point it at the operation that replaced its own, or keep it with the operation_id to come until the contract catches up. A note that names no API is not reported: it is a candidate for every contract of its source and may describe an API without a contract. A note taken in an ambiguity is reported by the matching rule instead. | 37 |
| Unreachable contract | warning | The contract an API note declares in its contract attribute, a URL or a path relative to the note, could not be fetched, read or parsed: the server answered with an error, the build ran without network access, the file is missing, or the document is neither an OpenAPI 3.x document in JSON or YAML nor a WSDL 1.1 or 2.0 document. No operation is imported from it, the note keeps the operations written by hand, and the build goes on; the API page has no imported operations until a later build reads the contract. A project whose contracts must be present raises the severity to error. | 23 |
5 contracts of 5 — pagination by twenty. The Links column counts the related pages, which brings the most central contracts of the journey to the top.