Summary
I noticed a response model that leaks an implementation detail which could be hidden by mapping data types using OpenAPI 3.0’s nullable
attribute.
Detail
Currently, nullable properties are referring to a definition found in this library for working with databases in Go GitHub - markbates/pop: A Tasty Treat For All Your Database Needs.
Since OpenAPI 3.0 supports describing nullable properties, this would be preferable over using the custom definition from the pop library.
In my case, this would reduce writing some boiler-plate code to convert the pop library type for a nullable String to Swift’s generic Optional data type, where I’m consuming the Bitrise API.
Current definition
"v0.BuildResponseItemModel": {
"type": "object",
"properties": {
"abort_reason": {
"$ref": "#/definitions/github.com_markbates_pop_nulls.String"
},
"github.com_markbates_pop_nulls.String": {
"type": "object",
"properties": {
"string": {
"type": "string"
},
"valid": {
"description": "Valid is true if String is not NULL",
"type": "boolean"
}
}
},
Proposed definition
"v0.BuildResponseItemModel": {
"type": "object",
"properties": {
"abort_reason": {
"type": string,
"nullable": true
},