-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(api): fix request and response types #4244
Conversation
|
||
@Operation(description = "Request all assets according to a particular query", | ||
operationId = "requestAssetV3", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some tools like API gateways use the operationId
to generate their internal routing model. removing it may pose a problem.
I guess the safest way is if we have both, distinct method names and operationIDs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
by default the operationId
reflects the method name, if the method is already called requestAssetV3
, explicitly defining the operationId
is not necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but doesn't that mean, that if an operationId
is present, it would override whatever the method name is?
and if so, naming the methods ...V3...
should not be necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is necessary to avoid the generated openapi mess (I debugged it, not sure about the root cause, but the rename thing definitely fixes the issue).
I see two appreciated side effects:
- it will avoid outdated
operationId
definitions (because they are sterile strings) - defining different method names for different versions makes total sense (think about a method that in 2 different versions has 2 different signatures/behaviors)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so long as it fixes the issue, i'm all for it. we need to be extra careful with method renaming though, as it could cause obscure behaviour in API gateways etc.
think about a method that in 2 different versions has 2 different signatures/behaviors
That shouldn't be a problem, since they'd live in different classes anyway.
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #4244 +/- ##
==========================================
- Coverage 71.74% 70.54% -1.20%
==========================================
Files 919 1046 +127
Lines 18457 20967 +2510
Branches 1037 1169 +132
==========================================
+ Hits 13242 14792 +1550
- Misses 4756 5680 +924
- Partials 459 495 +36 ☔ View full report in Codecov by Sentry. |
0894be0
to
c003c25
Compare
What this PR changes/adds
Why it does that
fix the api docs output (as outlined in #4243)
Further notes
removed all the unnecessary
operationId
attributes from@Operation
swagger annotationsLinked Issue(s)
Closes #4243
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.