mirror of
https://github.com/LukeHagar/redocly-cli.git
synced 2025-12-07 04:21:11 +00:00
88cd624d7a
* docs: Fix typo and remove reference to feature we're planning to drop * docs: re-word the rule explanation, add link to operationId blog post * docs: simplify rule description, pick more relevant related rules to link to * docs: simplify kebab-case explanation
2.0 KiB
2.0 KiB
slug
| slug |
|---|
| /docs/cli/rules/operation-operationId |
operation-operationId
Requires each operation to have an operationId defined.
| OAS | Compatibility |
|---|---|
| 2.0 | ✅ |
| 3.0 | ✅ |
| 3.1 | ✅ |
API design principles
The operationId is used by tooling to identify operations (which are otherwise done through scary looking JSON pointers).
OpenAPI does not consider operationId a required field, but we'd describe it as a strongly recommended field.
This rule is unopinionated.
Configuration
| Option | Type | Description |
|---|---|---|
| severity | string | Possible values: off, warn, error. Default warn (in recommended configuration). |
An example configuration:
rules:
operation-operationId: error
Examples
Given this configuration:
rules:
operation-operationId: error
Example of an incorrect operation:
paths:
/cars:
get:
responses:
'200':
$ref: ./Success.yaml
Example of a correct operation:
paths:
/cars:
get:
operationId: GetCar
responses:
'200':
$ref: ./Success.yaml
Related rules
Resources
- OperationIds make good API design - Redocly Blog
- Rule source
- Operation object docs
- Consider using configurable rules for more specific rules for
operationIds such as length, casing, and pattern enforcement.