Your usage of additionalProperties
is correct and your model is correct.
additionalProperties
In Swagger/OpenAPI, hashmap keys are assumed to be strings, so the key type is not defined explicitly. additionalProperties
define the type of hashmap values. So, this schema
type: object
additionalProperties:
type: string
defines a string-to-string map such as:
{
"en": "English text",
"de": "Deutscher Text"
}
If you needed a string-to-integer map such as:
{
"en": 5,
"de": 3
}
you would define additionalProperties
as having value type integer
:
type: object
additionalProperties:
type: integer
Required key in a hashmap
To define en
as a required key in the hashmap:
type: object
properties:
en:
type: string
required: [en]
additionalProperties:
type: string
Complete example
definitions:
delayReason:
type: object
properties:
id:
type: string
description: Identifier for a delay reason.
name:
type: object
description: A hashmap with language code as a key and the text as the value.
properties:
en:
type: string
description: English text of a delay reason.
required: [en]
additionalProperties:
type: string
required: [id, name]
example:
id: '123' # Note the quotes to force the value as a string
name:
en: English text
de: Deutscher Text
There is also no clue in this that the result will have a language code as a key and the text as the value of the hash map.
Things like that can be documented verbally in the description
.
the example also does not seem to work as expected. It generates an empty $folded: in the UI.
Not sure what the problem was with your original spec, but the spec above is valid and looks fine in the Swagger Editor.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…