-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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 Deprecation headers for legacy rest endpoints #7686
Conversation
Codecov Report
@@ Coverage Diff @@
## master #7686 +/- ##
=======================================
Coverage 54.12% 54.13%
=======================================
Files 611 611
Lines 38631 38639 +8
=======================================
+ Hits 20909 20917 +8
Misses 15590 15590
Partials 2132 2132 |
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.
Why you need to add a header for every endpoint? Can't you just set them globally in server/
or at least in the RegisterRESTRouters
of each handler? There should be a way to just attach middleware.
Swagger is out of date already and explicitly unmaintained afaik |
Wait are we merging the grpc gateway swagger with the old swagger? We shouldn't be doing that. Early on I was told that old swagger is unmaintained and we shouldn't bother with it. |
Yes, we merged legacy rest swagger and gRPC gateway swagger docs in #7246 . The only reason was to have a single endpoint for swagger docs. It's just a config change, we can just remove the rest swagger entry from |
Just switched to using I'll take a look more at this tomorrow and resolve. |
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.
(including tendermint rpc & /node_info)
Those should be deprecated too imo. If we want to keep them as REST, we should do so via grpc-gateway.
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.
Left just a tiny comment. Otherwise looks good
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
// Deprecation headers to a http handler | ||
func addHTTPDeprecationHeaders(h http.Handler) http.Handler { | ||
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { | ||
w.Header().Set("Deprecation", "true") |
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.
Do we also want to set Sunset
and or Warning
headers?
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.
Sunset
headers requires a specific date of sunset, I can add Warning
headers with essentially the same information, but a bit more verbose.
types/module/module.go
Outdated
@@ -110,8 +110,9 @@ func (bm BasicManager) ValidateGenesis(cdc codec.JSONMarshaler, txEncCfg client. | |||
|
|||
// RegisterRESTRoutes registers all module rest routes | |||
func (bm BasicManager) RegisterRESTRoutes(clientCtx client.Context, rtr *mux.Router) { | |||
r := rest.WithHTTPDeprecationHeaders(rtr) |
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.
Actually shouldn't be be doing this module by module? Putting this in BasicManager
means that other projects with other modules will have their REST routes auto-deprecated. That's not really what we want right?
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.
I thought this was what we wanted, as this entire process for generating REST routes will be deprecated at the SDK level in future releases, no?
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.
You're probably right... That would make SDK maintenance easier. Still this deprecation goes to clients. RegisterRESTRoutes
should be deprecated for module developers. Module developers may decide not to deprecate their own REST routes for clients and instead do that wiring on their own.
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.
Sorry- i'm not following exactly what you mean. Is this still something you are wanting changed? Or do you now think the current implementation is correct in the context of this PR?
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.
Yes It still should be their decision. So I would prefer we do module by module.
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.
REST routes for clients and instead do that wiring on their own.
This should be on by default to let the developers and users to know and prepare for that.
At some point we will remove the REST API.
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.
If we need to coustomze it at the SDK level, then we can add a parameter to the RegisterRESTRoutes
function:
RegisterRESTRoutes(clientCtx client.Context, rtr *mux.Router, deprecateREST bool)
Thoughts on if we should also be deprecating these routes? IMO these aren't as crucial to deprecate as they aren't made redundant by any new grpc-gateway routes. Would appreciate some other opinions on if these should be included or not (cc @aaronc, @anilcse, @alexanderbez) |
May be we should introduce respective gRPC gateway routes and mark these as deprecated. |
Agreed, we ideally want clients to have a single RPC layer they have to deal with that covers pretty much everything |
@amaurymartiny I wrote this up in an issue (#7719) so this discusison can happen separately, and tackled later depending on the path forward. @aaronc you still have |
@clevinson I responded stating that I still think other modules should get to decide if they deprecate. You didn't make the change or respond to my comment. |
* add deprecation headers for legacy rest endpoints * add deprecation headers for missing tx routes * rm handler-level deprecation headers * switch to middleware Route.Use method for setting deprecation Headers * set deprecation headers using subrouter * cleanup gofmt * goimports * Update client/rest/rest.go * update deprecation headers to be set on each module individually Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Description
closes: #7636
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes