tsp-openapi3 - add heuristics for operation response generation #5831
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chrisradek
requested review from
bterlson,
markcowl,
allenjzhang,
timotheeguerin and
witemple-msft
as code owners
|
All changed packages have been documented.
Show changes
|
|
You can try these changes here
|
chrisradek
commented
Feb 5, 2025
7 tasks
timotheeguerin
approved these changes
Feb 6, 2025
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
dmnorc
pushed a commit
to dmnorc/typespec
that referenced
this pull request
Feb 18, 2025
…osoft#5831) Fixes microsoft#3765 This PR primarily changes the way operation return types are handled when converting an Open API 3 doc to TypeSpec. Previously, a separate model was generated for every possible response per operation. This quickly exploded the number of models generated if multiple status codes or content types were defined for an operation. Now, those models are in-lined per operation rather than declared. Additionally, some heuristics are employed to trim down each model expression to remove fields that have TypeSpec-defined default values, and whose status code matches a model from the `@typespec/http` library. To support `@defaultResponse`, a `GeneratedHelpers.DefaultResponse` template is created - only when needed - and is referenced by the generated operations. I also made 3 changes related to response generation as part of this PR: 1. Response headers that use `$ref` are now supported 2. Responses that use `$ref` are now supported 3. Switched to using the OpenAPI parser's `$ref` resolution to resolve refs instead of the more fragile `$ref` string parsing that was being used before. Combined with using the parser's `bundle` feature (which was already used) - this should resolve any edge cases around following `$refs` that point to different files. ~TODO: double-check that the parser-related changes doesn't break the playground importer~ --------- Co-authored-by: Christopher Radek <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #3765
This PR primarily changes the way operation return types are handled when converting an Open API 3 doc to TypeSpec.
Previously, a separate model was generated for every possible response per operation. This quickly exploded the number of models generated if multiple status codes or content types were defined for an operation.
Now, those models are in-lined per operation rather than declared. Additionally, some heuristics are employed to trim down each model expression to remove fields that have TypeSpec-defined default values, and whose status code matches a model from the
@typespec/httplibrary.To support
@defaultResponse, aGeneratedHelpers.DefaultResponsetemplate is created - only when needed - and is referenced by the generated operations.I also made 3 changes related to response generation as part of this PR:
$refare now supported$refare now supported$refresolution to resolve refs instead of the more fragile$refstring parsing that was being used before. Combined with using the parser'sbundlefeature (which was already used) - this should resolve any edge cases around following$refsthat point to different files.TODO: double-check that the parser-related changes doesn't break the playground importer