OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
I have the following scenario: In an API I want to perform some PUT requests that only differ in their bodies. So what I did is declare a composed schema using oneOf in the request body section of my OAS 3 spec. The code generation performs quite badly on this input.
The implementation of DefaultCodegen gives up on inferring a good type for composed schemas very easily. Basically for an composed schema, you'll always end up with an unknown base type. See
I dislike this because of two reasons:
Some target languages might actually be able to infer a type that is the intersection of all models that are being composed, i.e. Intersection Types in TypeScript.
Even if there is no concrete type that matches the intersection or disjoint union of the models that represent the composed schemas, there might be other ways to escape this. For example, if the composed schema covers a request body and the target language supports method overloading, then you might generate a request method for every type in the composition separately.
By bailing out on the codegen layer, one will never be able to implement generators for this, and a quite handy use case is obstructed.
openapi-generator version
020883f (master from 2018-07-04)
OpenAPI declaration file content or url
Quite big, and I cannot make it public. The relevant part is:
patch:
operationId: card__edit
tags:
- cards
parameters:
- name: id
in: path
required: true
description: The id of the card to perform this action on
schema:
type: string
requestBody:
content:
"application/vnd.api+json":
schema:
oneOf:
- "$ref": "#/components/schemas/card__post"
- "$ref": "#/components/schemas/card__lock"
- "$ref": "#/components/schemas/card__unlock"
discriminator:
propertyName: modifying_action
mapping:
post: "#/components/schemas/card__post"
lock: "#/components/schemas/card__lock"
unlock: "#/components/schemas/card__unlock"
Description
I have the following scenario: In an API I want to perform some PUT requests that only differ in their bodies. So what I did is declare a composed schema using oneOf in the request body section of my OAS 3 spec. The code generation performs quite badly on this input.
The implementation of
DefaultCodegen
gives up on inferring a good type for composed schemas very easily. Basically for an composed schema, you'll always end up with an unknown base type. SeeI dislike this because of two reasons:
By bailing out on the codegen layer, one will never be able to implement generators for this, and a quite handy use case is obstructed.
openapi-generator version
020883f (master from 2018-07-04)
OpenAPI declaration file content or url
Quite big, and I cannot make it public. The relevant part is:
Command line used for generation
java -jar openapi-generator-cli.jar generate -g java -i api.yml -o jclient
Suggest a fix/enhancement
Remove any type inference logic from the codegen part and leave that to be handled in the generators.