You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Our API contains some subresources that are not easily modeled in an OpenAPI spec. To get around this, we want to punt by modeling them as "free form" objects (an object with additionalProperties: true) and interacting with them as plain dicts instead of model classes.
Describe the solution you'd like
Support for the additionalProperties key, ideally in both use cases - specifying additional properties and specifying a freeform object
Just using objects directly to declare these subresources instead of $refing a shared component schema to make it so the property gets generated as a plain dict.
Additional context
We do have a consistent model for the resource in question, just one that isn't easily modeled in OpenAPI. It's used as a property in several of our models so we would like to be able to indicate the relation by using a shared component schema.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Our API contains some subresources that are not easily modeled in an OpenAPI spec. To get around this, we want to punt by modeling them as "free form" objects (an object with
additionalProperties: true
) and interacting with them as plaindict
s instead of model classes.Describe the solution you'd like
Support for the
additionalProperties
key, ideally in both use cases - specifying additional properties and specifying a freeform objectAdditional properties:
Should generate a model like
Free Form Object:
Describe alternatives you've considered
Just using
object
s directly to declare these subresources instead of$ref
ing a shared component schema to make it so the property gets generated as a plaindict
.Additional context
We do have a consistent model for the resource in question, just one that isn't easily modeled in OpenAPI. It's used as a property in several of our models so we would like to be able to indicate the relation by using a shared component schema.
The text was updated successfully, but these errors were encountered: