Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should operation-operationId continue to exist? #7

Open
philsturgeon opened this issue Dec 28, 2022 · 0 comments
Open

Should operation-operationId continue to exist? #7

philsturgeon opened this issue Dec 28, 2022 · 0 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@philsturgeon
Copy link
Contributor

Where should operation-operationId exist (if it should continue to exist anywhere) once spectral:oas goes away, because it is not actually required in the OpenAPI spec.

Context

This is the old rule in spectral:oas:

    "operation-operationId": {
      message: "Operation is missing an operationId.",
      severity: DiagnosticSeverity.Error,
      recommended: true,
      given: "#OperationObject",
      then: {
        field: "operationId",
        function: truthy,
      },
    },

Current Behavior

Currently Spectral with the default spectral:oas ruleset will tell everyone that operation must have an operationId, but OpenAPI v3.x doesn't say that at all.

Unique string used to identify the operation. The id MUST be unique among all operations described in the API. Tools and libraries MAY use the operationId to uniquely identify an operation, therefore, it is RECOMMENDED to follow common programming naming conventions.

Notice that there is no REQUIRED: at the start, like other required properties.

image

Expected Behavior

As operationId is optional I think it should be deleted from here, and added to spectral-documentation. Or... does it even need to be added to documentation?

Fundamentally, what does this add?

Possible Solution(s)

I am removing it from https://github.com/philsturgeon/spectral-openapi so that when spectral:oas is deprecated and people switch to that repo it will be gone.

Should I add the rule to Spectral Documentation, under the assumption that documentation tools use this for something useful, or should I just let it vanish in the spectral:oas to spectral-openapi migration?

@philsturgeon philsturgeon added enhancement New feature or request question Further information is requested labels Dec 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant