-
Notifications
You must be signed in to change notification settings - Fork 134
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
Support for operations that respond with 1xx
status codes
#1529
Comments
Thanks for the question! The recommended ruleset is aimed at being a solid recommendation for people with a basic API and little knowledge about APIs, to get them started in their API governance journey. Once up and running, almost all organisations should adjust the ruleset to fit their context, and I think that's the best approach here. I'll close the issue since there's no action planned on our side, but please stay in touch if you have more comments or questions for us. |
@lornajane Understood on the goals of the recommended ruleset, but to be clear: we consider the |
Yes there is! You can set an ignore for just the specific things you want to avoid having reported. The docs you want are over here: https://redocly.com/docs/cli/commands/lint/#generate-ignore-file |
@lornajane Unfortunately, with the ignore file approach, I end up with a problem similar to that described by #1224, as we generate multiple variants of our API (and furthermore, in our CI they are generated in temporary directories). The solution in #1224 seems to be to create a custom plugin with an extension, but it is not clear to me how to write an extension for |
Hi @HenryGessau, there is yet another option to solve your case. While you can still use the extends:
- recommended
rules:
operation-2xx-response: off
rule/operation-1xx-or-2xx-response:
subject:
type: Responses
assertions:
requireAny:
- '101'
- '200'
- ...
And then add as many required response codes as you need (probably all |
Is your feature request related to a problem? Please describe.
Some APIs have operations that respond with
1xx
instead of2xx
status codes. A common example is101 Switching Protocols
for supporting WebSockets.A design utilizing
1xx
status codes is not indicative of a bad API, and should therefore be accepted by the recommended ruleset. However, it runs afoul of the recommendedoperation-2xx-response
rule.Describe the solution you'd like
I see a couple of possibilities:
operation-2xx-or-1xx-response
.alsoAllow1xxResponse
to theoperation-2xx-response
rule.I am sure there are other viable approaches.
Describe alternatives you've considered
I could configure an override for my specific operations that return
101
. However, it feels wrong to have this configuration for an otherwise good API.Additional context
Not all
1xx
status codes are equally good. In particular,102 Processing
is deprecated.The text was updated successfully, but these errors were encountered: