Support multiple response class depending on an input parameter

[perabello]

I have a get operation that return two different classes (and it could be more) depending on a parameter input.
I could resolve it separating to multiple operations. One for each result class.
But it forces me to add a path for the GET.
Example: /persons/{id}/info=?
It returns PersonDto or EmployeeDto for BASIC or EMPLOYEE parameter.
The result are two classes totally different.
And I don't want to publish something like: /persons/{id}/full

[fehguy]

Hi, this may be outside of swagger's goals. Think of it like this. The consumer needs to know the business logic for the return type as a function of input. That's putting them in a position to fail.

The only mechanism with swagger right now is to use different return codes (i.e. 200, 201, etc) to indicate different models.

If you want, you can file a ticket in the swagger-spec repo for this

[webron]

Tony, this is the swagger-spec repo.

Basically what's being described here is a request to treat a combination of path+httpmethod +query parameter as a unique operation rather than path+httpmethod only.

[fehguy]

Yes, i misread the repo, i need my bifocals. Sorry about that @perabello

[webron]

This did not make it into Swagger 2.0, mostly for the reasons @fehguy mentioned. I'm closing this issue for now and marking it as a proposal for the next version instead of rejecting it.
However, I'm really not sure we want to allow such API documentation.

[webron]

Parent: #574.

[RobDolinMS]

@perabello Is this still an issue with the latest OAI v3 draft?

[webron]

@RobDolinMS - There's no solution for this in 3.0. Given that this didn't get much traction, I'll close it now. We can revisit if we get more requests for it.

[madorb]

Stinks that this is closed. This would be so incredibly useful.

being able to treat:
GET /foo?view=full returning a list of fully hydrated foos vs
GET /foo?view=compact returning say, a list of ids for instance would be incredibly useful to have in the spec

as distinct endpoints would be incredibly useful.