kin-openapi
kin-openapi copied to clipboard
Support for array in type keyword
According to the json schema upon which OpenAPI spec relies, type
keyword can be either a string or an array.
The value of this keyword MUST be either a string or an array. If it is an array, elements of the array MUST be strings and MUST be unique. https://datatracker.ietf.org/doc/html/draft-wright-json-schema-validation-00#section-5.21
Using this feature in an OpenAPI spec v2 prevents parsing
The following snipped
...
"definitions": {
"budgetCode": {
"type": [
"string",
"null"
],
"format": "nullable string"
},
...
produces
2022/06/30 14:02:18 Failed de decode OpenAPI Spec: failed to unmarshal property "definitions" (*map[string]*openapi3.SchemaRef): failed to unmarshal property "properties" (*openapi3.Schemas): failed to unmarshal property "type" (*string): json: cannot unmarshal array into Go value of type string
Indeed you're right. From https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#schema-object I arrive at a similar passage of https://datatracker.ietf.org/doc/html/draft-fge-json-schema-validation-00#section-5.5.2.1
Same for OpenAPIv3.1 https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-00#section-7.6.1
In OpenAPIv3.0 type
can only take a single string value per https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#properties and the code in ./openapi2
relies on that implementation.
So here's what needs to happen:
- Clone the struct
*openapi3.SchemaRef
in./openapi2
, making suretype
can take bothstring
and[]string
and removing non-v2 fields if any. - Replace the corresponding code in
openapi2_conv.go
so the newly introduced struct is used.
When converting type
from v2 to v3 you can use this equivalence:
'Legal in v2':
type: [boolean, string]
'Legal in v3.0':
oneOf:
- {type: boolean}
- {type: string}
Please send PRs my way! :)
@fenollp Working on a PR.
Not too sure at the moment what should be the behaviour of the code at https://github.com/getkin/kin-openapi/blob/master/openapi3/schema.go#L655 where we must validate the format associated with the type and we have multiple types. Do we have any reference to this case in the specs?
I guess the format should not be specified if multiple types are provided...
@rodcloutier have you made any more progress on this? @fenollp any advice for rod?
Depending on the status of this, it might be something I will need to pick up soon if we aren't close to a solution?
@TristanSpeakEasy If you wish you can take over the work. I haven't had time to make any progress.