Skip to content
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

Merged
merged 10 commits into from
Oct 29, 2020

Conversation

clevinson
Copy link
Contributor

@clevinson clevinson commented Oct 27, 2020

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.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@codecov
Copy link

codecov bot commented Oct 27, 2020

Codecov Report

Merging #7686 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           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           

Copy link
Member

@aaronc aaronc left a 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.

@aaronc
Copy link
Member

aaronc commented Oct 27, 2020

x/bank/client/rest/query.go Outdated Show resolved Hide resolved
x/bank/client/rest/query.go Outdated Show resolved Hide resolved
x/evidence/client/rest/query.go Outdated Show resolved Hide resolved
x/slashing/client/rest/query.go Outdated Show resolved Hide resolved
x/upgrade/client/rest/query.go Outdated Show resolved Hide resolved
@aaronc
Copy link
Member

aaronc commented Oct 27, 2020

Swagger is out of date already and explicitly unmaintained afaik

@clevinson
Copy link
Contributor Author

clevinson commented Oct 27, 2020

@aaronc then why did we go through the work of updating it with all the GRPC Gateway routes?

Currently most of the legacy routes are marked as "Deprecated" in the swagger as well. I think @anilcse was largely the one updating all of this.

What do you mean by explicitly unmaintianed?

@aaronc
Copy link
Member

aaronc commented Oct 27, 2020

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.

@anilcse
Copy link
Collaborator

anilcse commented Oct 27, 2020

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 client/docs/config.json and regenerate swagger docs.

@clevinson
Copy link
Contributor Author

clevinson commented Oct 27, 2020

Just switched to using Route.Use with a middleware func, but that seems to be affecting the entire server (including tendermint rpc & /node_info) as the rtr is passed in by reference in RegisterRESTRoutes...

I'll take a look more at this tomorrow and resolve.

Copy link
Contributor

@amaury1093 amaury1093 left a 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.

x/auth/client/rest/rest.go Outdated Show resolved Hide resolved
Copy link
Contributor

@alessio alessio left a 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

Copy link
Member

@aaronc aaronc left a 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")
Copy link
Member

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?

Copy link
Contributor Author

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.

@@ -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)
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Member

@aaronc aaronc Oct 28, 2020

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.

Copy link
Contributor Author

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?

Copy link
Member

@aaronc aaronc Oct 29, 2020

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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)

@clevinson
Copy link
Contributor Author

Those should be deprecated too imo. If we want to keep them as REST, we should do so via grpc-gateway.

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)

@anilcse
Copy link
Collaborator

anilcse commented Oct 28, 2020

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.

@aaronc
Copy link
Member

aaronc commented Oct 28, 2020

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

@clevinson
Copy link
Contributor Author

(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.

@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 Changes requested status. Can you mark as approved or elaborate what still needs changing from your side?

@aaronc
Copy link
Member

aaronc commented Oct 29, 2020

@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.

@aaronc aaronc added the A:automerge Automatically merge PR once all prerequisites pass. label Oct 29, 2020
@mergify mergify bot merged commit 536eb68 into master Oct 29, 2020
@mergify mergify bot deleted the clevinson/legacy-deprecation-headers-7636 branch October 29, 2020 11:37
clevinson added a commit that referenced this pull request Oct 29, 2020
* 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>
@amaury1093 amaury1093 mentioned this pull request Jul 20, 2021
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add HTTP Deprecation header to legacy REST endpoints
7 participants