Make WordPress Core

Opened 8 years ago

Closed 7 years ago

#38339 closed enhancement (wontfix)

Add unregister_rest_route helper

Reported by: rmccue's profile rmccue Owned by: rmccue's profile rmccue
Milestone: Priority: normal
Severity: normal Version: 4.4
Component: REST API Keywords:
Focuses: Cc:


To fit with register_rest_route, we should add an unregister_rest_route that allows removing routes if the site developer or plugins want to remove specific routes. This allows them to selectively reduce the attack surface of the API if they're concerned about it, or simply disable pieces they don't need in an easier way than the existing rest_endpoints filter.

Change History (11)

#1 @jnylen0
8 years ago

It should also be possible to guarantee that the same endpoint isn't re-registered later in the request or executed as part of an _embed response. It would also be nice to be able to exclude entire groups of endpoints at once. Maybe a filter like rest_is_route_allowed would be a more flexible way to achieve the same thing.

This ticket was mentioned in Slack in #core by jnylen. View the logs.

8 years ago

#3 @jorbin
8 years ago

  • Owner set to rmccue
  • Status changed from new to assigned

#4 @flixos90
8 years ago

I don't like the idea of adding this function too much, since I feel like it would encourage developers to unregister endpoints they don't need. This can easily lead to issues with both Core and plugins which might rely on these endpoints. It's easy to check for a plugin whether the entire REST API has been disabled, but doing these checks for individual endpoints would be a pain.

Since it is already possible to remove endpoints for those who absolutely want to do it (just a bit more complicated), I think we're fine like that for the above reasons (it's not that obvious). Yet, for the endpoints introduced by Core itself, I think these shouldn't be removed ever. I would rather vote for a similar behavior like we do it with the Core post types and taxonomies, pass something like a _builtin argument to them, thus preventing deletion.

#5 @jorbin
8 years ago

I'm opposed to the removal of routes. While I could see benefit to limiting requests to only registered users, I think the outright removal of routes means that core can not rely on core functionality. This is paramount to adding in the ability to easily break your site.

#6 @pento
8 years ago

I agree with @flixos90 and @jorbin on this - the core endpoints absolutely should not be able to be unregistered.

I'm a little more ambivalent about custom endpoints, but I'd like to know a use case that existing functionality doesn't already cover.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.

7 years ago

This ticket was mentioned in Slack in #core by stevenkword. View the logs.

7 years ago

#9 @stevenkword
7 years ago

  • Milestone changed from 4.7 to Future Release

#10 @jnylen0
7 years ago

I'd like to know a use case that existing functionality doesn't already cover

We need to restrict several endpoints in various ways on, but we can do it using existing filters.

Seems like the consensus is that this can be closed. Some related discussion in #38446 as well.

Last edited 7 years ago by jnylen0 (previous) (diff)

#11 @pento
7 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Thanks for the feeback, @jnylen0.

There are existing ways to remove endpoints, but explicitly encouraging that is a bad time for all involved.

Note: See TracTickets for help on using tickets.