about how I might document in Swagger a field whose type might vary. Swagger didn't really have a way of defining this, so we ended up with this sort of model.
"Obj": { "id": "Obj",
"properties": {
"foo": { "type": "Foo" },
"bar": { "type": "Bar" },
"bam": { "type": "Bam" }
}
}
Actually, you can see exactly
what our model is. As we're getting more into it, users of the API are having trouble using it. Inferring the type from the field name is really awkward. We could add a type field which gives the name of the data field, which makes things only slightly awkward. It also irks me to have redundant information in the message ({ "type": "foo", "foo": {}}).
So I'd like to go down the path of adding either subclassing or discriminated unions to Swagger model definitions.
Since Swagger models will need to map to statically typed languages, I think a subclassing approach might be best. Here's what a model might look like:
{ "id": "Base",
"properties": {
"type": { "type": "DISCRIMINATOR" },
...
}
}
{ "id": "Foo", "extends": "Base", "properties": { ... } }
{ "id": "Bar", "extends": "Base", "properties": { ... } }
{ "id": "Bam", "extends": "Base", "properties": { ... } }
{ "id": "Obj",
"properties": {
"data": { "type": "Base" }
}
}
And some examples of Obj:
{ "type": "Foo", "foo-specific": "whatever" }
{ "type": "Bar", "foo-specific": "whatever" }
etc.
Thoughts on this approach?
--