-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
Definitions for error responses #398
Comments
+1 for this, in the 1.2 spec as the response messages was a list you could have multiple messages for the same http error code, now in 2.0 as its a dict you cant have that, we use this a lot in our apis e.g. https://api.car.ma/apidoc/ref/bookings.json see related swagger-ui issue |
code: 4000, message: ... If I want to define the above spec in API response, how should I do it? I think it is not schema, right? |
If it's just a string, you can only define it as a string. If it has a structure like JSON then yeah, it's a schema. |
Schema is just a structure with key and data type for the key, but I need to supply this schema with some instance of filled data. Right now, I am just putting it in description. Is there a better way to do it? |
Have you seen the examples property? |
Thanks for reminding me! examples looks like a better place to put the data. I added example in YAML but it doesn't show up on the compiled UI. Is this the intended behavior? |
I'm not entirely sure what you mean by compiled UI... Some tools may not support the display of it yet. If you find that's the case, please open an issue on the relevant project. |
I mean this will not show examples in responses object. Thank you very much for helping me with this issue! |
Yeah, I don't think the editor currently renders the examples. Feel free to open a ticket about it on swagger-editor. |
Link to meta #566 |
This adds some common error responses to all endpoints in our OpenAPI spec. Unfortunately OpenAPI does not provide a nice way to handle these in a single place, so there's a lot of duplication. - See OAI/OpenAPI-Specification#398, OAI/OpenAPI-Specification#521, OAI/OpenAPI-Specification#566. The error responses also include some examples that will hopefully be useful for users and developers. However the examples are by no means exhaustive.
This adds some common error responses to all endpoints in our OpenAPI spec. Unfortunately OpenAPI does not provide a nice way to handle these in a single place, so there's a lot of duplication. - See OAI/OpenAPI-Specification#398, OAI/OpenAPI-Specification#521, OAI/OpenAPI-Specification#566. The error responses also include some examples that will hopefully be useful for users and developers. However the examples are by no means exhaustive.
This adds some common error responses to all endpoints in our OpenAPI spec. Unfortunately OpenAPI does not provide a nice way to handle these in a single place, so there's a lot of duplication. - See OAI/OpenAPI-Specification#398, OAI/OpenAPI-Specification#521, OAI/OpenAPI-Specification#566. The error responses also include some examples that will hopefully be useful for users and developers. However the examples are by no means exhaustive.
Since nothing else can be done about this in 3.x, I'm going to mark this "Moved to Moonwalk" and close it. |
It's obvious that each api will have a bunch of errors. Each request can usually raise one of several errors (where subsets can differ for different routes).
Current scheme allows only one response with given status code. While this is generally okay for successful responses (like
200 OK
,301 Redirect
etc) it doesn't play well with codes above 400. For example,400 Bad Request
can be caused by many reasons, such as missing fields, extra fields, incorrect data or other preconditions. It is required to let client know what errors can he expect for each request and what playload (if any) will each error have.This all leads to a requirement of having errors (or exceptions) definition.
It can be similar to current
responses
section, and each request method would have list of errors (exceptions?) that might be raised.Another useful thing is to have api-wide exceptions. The best examples of such are
401 Unauthorized
and500 Server Error
as they can be raised almost by any request.The text was updated successfully, but these errors were encountered: