Skip to content

Missing Error Definitions or References in 9 Swagger Specs #252

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

Closed
selvasingh opened this issue Apr 19, 2016 · 7 comments
Closed

Missing Error Definitions or References in 9 Swagger Specs #252

selvasingh opened this issue Apr 19, 2016 · 7 comments
Assignees

Comments

@selvasingh
Copy link
Contributor

Missing Error Definitions or References in 9 Swagger Specs

Notification Hubs REST API throws several error codes however its Swagger does not define any of these.

Search REST API throws several error codes however its Swagger does not define any of these.

Azure Active Directory Graph API throws several error codes however its Swagger does not define any of these.

So on and on ...

@devigned
Copy link
Member

Which error codes are you referring to? Please be specific or the issues will be long lived and difficult to determine if they are completely resolved.

@selvasingh
Copy link
Contributor Author

@devigned - if you go to their corresponding REST API specs, then you can see it. I provided some examples in the first comment

@devigned
Copy link
Member

@Azure/adx-autorest-contributors and @Azure/openapi-advisors any thoughts on this issue?

@brjohnstmsft
Copy link
Member

@devigned Two thoughts, one specific to Search, one general:

  1. The Search Swagger specs are not what I would call "production-ready" yet. We have an issue open to decide what to do about this: OpenAPI specs that are not complete should not be in master #195 It would be great to close on it so we can be omitted from these sweeps until we are ready.
  2. From a codegen standpoint, would adding the additional error codes change anything? For example, in C#, AutoRest basically assumes that success means return a response, while failure means throw a CloudException. I'm confident we have already captured all the success cases in the Search specs. Other than for documentation purposes, is there any value in explicitly enumerating all the possible failure cases in the specs?

@devigned
Copy link
Member

devigned commented May 9, 2016

OAI/OpenAPI-Specification#566 <-- to help follow 3.0 suggestions

@devigned
Copy link
Member

We should have a shared (common) set of schema, a base error should be returned by default (non-success responses) specialized by the error code via a polymorphic discriminator. This will provide the information to specialize the initialized class as well as the to document all of the possible error responses.

@devigned devigned self-assigned this May 10, 2016
@kirthik
Copy link
Contributor

kirthik commented Feb 10, 2017

Closing since this is being tracked here - Azure/autorest#1523.

@kirthik kirthik closed this as completed Feb 10, 2017
blueww pushed a commit to blueww/azure-rest-api-specs that referenced this issue Dec 8, 2017
[ACS,AKS] remove "count" from required fields since it has a default
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants