TO-Perl currently has full CRUD API support for both /capabilities and /api_capabilities. It seems to me like capabilities are statically-defined in terms of what the actual capabilities of the system are at the current version (via seeds.sql), so we don't really need API-level support for Creating/Updating/Deleting capabilities. That just seems like a footgun that we can easily eliminate from the system altogether. I _do_ still think we should be able to READ the existing capabilities via the API (for knowing what capabilities can be added to a role), but that's about it.
If a TO extension adds a new route and wishes to use roles/capabilities, it should insert its own capabilities into TODB at startup/load time. So, I would vote that we deprecate all Create/Update/Delete endpoints for /capabilities and /api_capabilities, and by that I mean not rewriting them to Go and changing the Perl routes to add a deprecation alert. Although, API promises and what-not aside, I think we could probably just delete the Perl routes right now because I can't imagine a valid reason to even be using those endpoints currently. - Rawlin On Thu, Aug 15, 2019 at 12:15 PM ocket 8888 <[email protected]> wrote: > > I recently marked a PR that rewrites the `/capabilities` endpoint in Go as > ready for review (https://github.com/apache/trafficcontrol/pull/3870) and > with it added handlers for PUT and DELETE. That means that > `/capabilities/{{name}}` will no longer do anything that `/capabilities` > does not, so is it alright if we deprecate it? > > There's also been some discussion about deprecating the ability to > create/modify/delete capabilities at all (mostly on that PR itself, atm). > I'd like to answer my above question before we get into that, though.
