[Rust Server] Support types with additional properties #3666
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR checklist
Read the contribution guidelines.
Ran the shell script under
./bin/
to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.sh
,./bin/openapi3/{LANG}-petstore.sh
if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\
. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.Filed the PR against the correct branch:
master
,4.1.x
,5.0.x
. Default:master
.Copied the technical committee to review the pull request if your PR is targeting a particular programming language.
Description of the PR
This adds support for types which only contain additional properties, which is a common use case. It doesn't handle the thornier case of additional properties within a type with defined properties, which is allowed by the OpenAPI spec, but is more dubious API design in practice (as the API is mixing schema-ed and un-schema-ed data).
Note, this will also only fix the case where the type is defined (e.g. string) - if it's untyped, it remains unsupported.
This thus partially fixes #318
An example of something this will support is already defined in the sample API: