I have a series of parameters in Swagger like this
"parameters": [
{
"name": "username",
"description": "Fetch username by username/email",
"required": false,
"type": "string",
"paramType": "query"
},
{
"name": "site",
"description": "Fetch username by site",
"required": false,
"type": "string",
"paramType": "query"
},
{
"name": "survey",
"description": "Fetch username by survey",
"required": false,
"type": "string",
"paramType": "query"
}
],
One parameter MUST be filled out but it doesn't matter which one, the others can be left blank. Is there a way to represent this in Swagger?
What about changing your API design ? Currently you have one method, 3 parameters. If I understand well, user must always provide exactly one parameter, and two remaining ones must be unset.
For me, API would be more usable with three endpoints -like
An alternative is to pass in a filter type parameter with an enum, and a filter value with the value to use.
Example at: https://app.swaggerhub.com/api/craig_bayley/PublicAPIDemo/v1
It can be required or not, as you choose. However if one is required, they should both be.
Unfortunately this isn't possible in Swagger currently. "required" is just a boolean and there's no way to represent interdependencies between parameters.
Best you can do is make clear the requirements in the parameter descriptions and also put in a custom 400 Bad Request description along the same lines.
(There's a bit of discussion at https://github.com/swagger-api/swagger-spec/issues/256 about possible ways of implementing this in the next version of Swagger)
Mutually exclusive parameters are possible (sort of) in OpenAPI 3.0:
oneOf
ormaxProperties
to limit the object to just 1 property.style: form
andexplode: true
, so that the object is serialized as?propName=value
.An example using the
minProperties
andmaxProperties
constraints:Using
oneOf
:Another version using
oneOf
:Note that Swagger UI and Swagger Editor do not support the examples above yet (as of March 2018). This issue seems to cover the parameter rendering part.
There's also an open proposal in the OpenAPI Specification repository to support interdependencies between query parameters so maybe future versions of the Specification will have a better way to define such scenarios.