-
Notifications
You must be signed in to change notification settings - Fork 134
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
Add note about the status of the legacy HTTP API. #531
Conversation
CC @bobcallaway @haydentherapper Let me know if my understanding isn't quite right; I'm happy to revise the docs. |
I think I'd like a stronger statement, something like "All features should be ported to legacy HTTP API. If there's a feature that you think would negatively impact the HTTP API, open an issue to discuss." The new gRPC API does support calls over HTTP too. I'd propose that we keep both APIs around through the V1 launch, and consider removing the legacy API closer to a V2 launch, unless maintenance of both is trivial. |
Roger. I cribbed that word-for-word, and added it in both |
Looks good! I'll let Bob do the approval for the PR, in case he had a different plan in mind for the legacy HTTP API. |
My intent in naming the I'm not supportive of having two functionally equivalent HTTP API endpoints with semantic differences that introduce technical debt and client confusion. +1 to making the above intent more explicit in the code comments, as well as making explicit that all additions/changes to the v2 API need to include HTTP support so as to not make gRPC a requirement for clients. |
+1 to the sentiment, @bobcallaway; that's what I had initially assumed and then some confusion in that regard was what prompted this. What I found when I asked at the community meeting last week was that there was general support for maintaining both, though I'm not sure whether any of those opinions were strongly held. I'm happy to revise but want to double check whether there's any reason to keep updating the old one? If we're ensuring that the new API works over HTTP I can't think of any. CC @haydentherapper, do you remember who else was saying we should backport stuff? |
There was a thought that clients may want to keep the legacy API around longer, but given that the V2 endpoint supports both gRPC and HTTP, just keeping V2 should be fine. +1 to what's been said - Let's close V1 to further feature development, and encourage clients to move off V1. |
@znewman01 do you want to change this PR to update the wording or do you want me to do that in a separate PR? |
@bobcallaway I'll do it! |
Signed-off-by: Zachary Newman <[email protected]>
Just pushed; should be ready for a look. |
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.
1 nit but the intent is clearer, thanks for revising this!
Co-authored-by: Bob Callaway <[email protected]> Signed-off-by: Zachary Newman <[email protected]>
Done |
Codecov Report
@@ Coverage Diff @@
## main #531 +/- ##
==========================================
+ Coverage 33.75% 35.68% +1.93%
==========================================
Files 18 18
Lines 1357 1415 +58
==========================================
+ Hits 458 505 +47
- Misses 836 851 +15
+ Partials 63 59 -4
Continue to review full report at Codecov.
|
Summary
Small doc clarification about the legacy HTTP API.
Ticket Link
No ticket, but this came up in the 2022-04-19 community meeting.
Release Note