-
Hey there, quick question (not quite an issue yet): In most cases, these fields are mandatory. See for example "PlanetInfo": {
"type": "object",
"description": "Represents information of a planet from the 'WarInfo' endpoint returned by ArrowHead's API.",
"additionalProperties": false,
"properties": {
"index": {
"type": "integer",
"description": "The numerical identifier for this planet, used as reference by other properties throughout the API (like Waypoints).",
"format": "int32"
},
"settingsHash": {
"type": "integer",
"description": "Purpose unknown at this time.",
"format": "int64"
},
"position": {
"description": "A set of X/Y coordinates specifying the position of this planet on the galaxy map.",
"oneOf": [
{
"$ref": "#/components/schemas/PlanetCoordinates" // <- here
}
]
},
// ... Now, from a OpenAPI perspective, this is perfectly fine. The problem I have is the following: I currently use a client code generator in my project which reads through your OpenAPI spec and produces client code for the requests in the spec. This is where the problem with Sample client code (Go)// MustPlanetPosition implements a converter for a planet position (i.e. coordinate).
func MustPlanetPosition(source *api.Planet_Position) ([]float64, error) {
if source == nil {
return nil, errors.New("Planet position is nil")
}
parsed, err := source.AsPosition() // convert ambigous type into actual type
if err != nil {
return nil, err
}
if parsed.X == nil || parsed.Y == nil {
return nil, errors.New("Planet position coordinates are nil")
}
return []float64{*parsed.X, *parsed.Y}, nil
} This method receives the immediate (generated) API response struct, but needs to perform additional processing in While I can see the usecase of this for actual ambigous types such as your recently-added localized strings, the example above and almost all other occurences of This is where my request comes in: is it possible to switch to I am aware that the OpenAPI specs are automatically generated from your C# source code, but perhaps there is a way of annotating such fields so that Thanks for reading this far, I hope this wall of text was half understandable. And just to be clear: it works the way it currently is, it just produces a lot of boilerplate code on my end, so I understand if this problem is too niche and thus not worth the effort. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
there's currently no specific reason we're using I'd say this can definitely be opened as a feature request |
Beta Was this translation helpful? Give feedback.
there's currently no specific reason we're using
oneOf
aside from the OpenAPI generator generating this by default.I'd have to look into if/how this can be configured by NSwag, but I see no problems in switching from
oneOf
toallOf
especially if this simplifies generated code.I'd say this can definitely be opened as a feature request