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

Configurable operationId naming convention #148

Closed
fenuks opened this issue Feb 26, 2020 · 3 comments
Closed

Configurable operationId naming convention #148

fenuks opened this issue Feb 26, 2020 · 3 comments
Assignees

Comments

@fenuks
Copy link

fenuks commented Feb 26, 2020

#124 adds linting naming conventions for operationId, but apparently, there is no option to disable it, or change which verbs are in convention, e.g. in my case I would like to use search verb instead of list when GET endpoint has parameters, since in my API, it's always a search operation.

openapi-validator version: 0.24.0

@dpopp07
Copy link
Member

dpopp07 commented Feb 26, 2020

@fenuks There should certainly be a way to disable it. If that is not currently implemented, we will fix that.

As for custom verbs, that would require more effort and we may not be able to prioritize that at the moment. We can look into it though.

@fenuks
Copy link
Author

fenuks commented Feb 27, 2020

Thank you, of course it's understandable that custom verbs is not something that is highly needed, especially that current ones work for you.

As for disabling this rule, I believe there is no possibility now, there is no mention in documentation about it, beside that I quickly skimmed through code, and to my understanding, there is no switch to turn checking off.

@dpopp07
Copy link
Member

dpopp07 commented Feb 27, 2020

I confirmed that you are correct - there is no way to configure this option. This needs to be fixed soon. @barrett-schonefeld @presto21 will one of you take on this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants