-
Notifications
You must be signed in to change notification settings - Fork 325
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
Swagger page per internal endpoint #3094
Swagger page per internal endpoint #3094
Conversation
didn't look at the code, just general questions. feel free to ignore me until i've filed a proper review.
why is value level superior? :) anyway, i'll read it first, then complain. why does legalhold has its own page?
so this PR undoes that solution? (no objection, just asking)
did the same limitation hold for the above solution if we decide to live with this limitation (fine by me), we should document on docs.wire.com or (better yet) on the swagger pages in the info heading. |
Some answers... 😄
IMHO it's easier to understand how the Swagger docs are rendered on value level. Probably, that's a matter of taste. This change is a bit orthogonal to the rest: I could add
Yes, no more prefixes as those aren't valid paths. (valid == A path that you may use to query a service.)
The prefixed paths were not executable at all. The improvement of this PR is that the rendered Our Servant servers seem to not handle CORS headers. So, we have three options here:
I decided to apply the third option, because it's the simplest. (Finally, this in only about Swagger... 😉 )
Is that wrong? I just found this API and used it without really knowing anything about legalhold... 🙄 |
I'd say, it's wrong. legalhold is not a stand-alone service like brig, galley, etc. |
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.
LGTM
2659bbf
to
d0cbb25
Compare
This PR renders a Swagger page per internal endpoint. The benefit is that we don't have to play crazy tricks to get all (overlapping!) paths right. Currently, this is solved in
develop
by prefixing the paths by their service name (e.g./<brig>/i/status
.)Executing the swagger operations by clicking on
Execute
doesn't work and never will: The services do not handle CORS related headers. Thus, the browser refuses to accept the response. But, the renderedcurl
command works ifkubectl forward-port
is called as described.This PR has been inspired by this comment: #3007 (comment)
And, I've removed
SwaggerTag
, because it's as simple to get its benefits on value level.Rendered
Checklist
changelog.d