I'm trying to spec a requestBody which conforms this:
{
"caseT": {... spec T...} "exts": {"caseU": {... spec U...}, "caseX": {... spec X...} } }
There are a number of known cases, the names are known - this means, all possible keys are known (case T, case U, case X, case ..., this is limited). For each case, the spec is known as well (there's no problem with modelling the specs).
Where I'm struggling a bit with is: how can I make sure that
Is this possible, of how can this be modelled as closely as possible in openapi 3.0?
see also my comment on github:
Unfortunately, there's no way to define that.
You can say that the top-level object can have at most 1 property, but that won't allow to add 'ext', or 2 properties, but that can also allow 'Case T' and 'Case X' to co-exist. Under 'ext', each case can exist only once as a key as they have to be unique, but you can't force it to not be the same case as the root level.
Too bad... any plans to support something like ajv or so (which makes some more logic possible)?
In future versions of the spec (which is controlled by the OAI, not SmartBear), there may be support for newer versions of JSON Schema, which might be able to define such additional logic.
Subject | Author | Latest Post |
---|---|---|