-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Ability to describe multiple success entities #2277
Comments
I dislike APIs that return two different types of things, but it's a matter of preference, so the proposal makes sense. Want to give it a try? |
Yeah, I'd like to try. Will send a pr when it's ready |
Well, after some research I realised that limitation was from OpenAPI 2.0. It does not support multiple response schemas per status code. |
But is it a grape-swagger problem or a grape problem? Can we do one without the other? |
Grape-swagger actually is able to accept an array in success section, but then in desc 'user' do
success [{ code: 200, model: Entities::User }, { code: 200, model: Entities::Admin }]
end In swagger you'll see only Entities::Admin as a result for 200. If you pass entities with different codes they will appear in swagger correctly. "paths": {
"/user": {
"get": {
"description": "user",
"produces": [
"application/json"
],
"responses": {
"200": {
"description": "user",
"schema": {
"$ref": "#/definitions/User"
}
}
},
"tags": [
"user"
],
"operationId": "getUser"
}
}
} And you can't pass an array to |
Looks like a bug in grape-swagger, which should raise an error here, short of supporting openapi 3. For Grape though I don't see a reason not to implement it. If someone ends up using it and swagger has a problem with it, 🤷 |
Sometimes it's necessary to return different entities depending on internal business logic. It would be nice to be able to document all possible success entities. Like with
failure
method but without status codes.Something like this:
The text was updated successfully, but these errors were encountered: