That said, I could get behind deprecating the ability to mutate capabilities through the API, as long as there's a simple way for extensions to declare their capabilities. Ideally that wouldn't mean an extension needs to manually access the database.
On Thu, Aug 15, 2019 at 1:35 PM ocket 8888 <[email protected]> wrote: > Well, we've immediately derailed, lol. I just want to know if I can mark > `/capabilities/{{name}}` as deprecated. > > But if we're going to discuss this immediately, here's my two cents: We've > committed to API versioning. That means that you can't remove an endpoint > that existed in version 1.x without moving to 2.x. So not rewriting all of > the Perl endpoints under `/api/1.x/` would mean that we're committed to > Perl sticking around until API 2.x. I think that's a bad idea, because the > codebase gets much easier to work with when there's only set of source for > a particular component. > > You can't deprecate an endpoint in ATC version N and remove it in N+1, > because the ATC version does not govern the TO API (except insofar as I > believe introducing 2.x would necessitate bumping the ATC version). > > Of course, we could always just _not_ version the API explicitly, which is > A-OK by me. But we've had that discussion before, and this particular email > thread isn't the place to re-hash it. > > On Thu, Aug 15, 2019 at 1:16 PM Rawlin Peters <[email protected]> > wrote: > >> On Thu, Aug 15, 2019 at 1:01 PM Robert Butts <[email protected]> wrote: >> > >> > >- don't bother converting `/capabilities/{{name}}` from Perl to Go >> > >> > But we still have to support those routes, until API 1.x is no longer >> > supported, which is far in the future. >> > >> > We should still rewrite deprecated Perl routes in Go, just so we can get >> > rid of Perl sooner than that. >> >> I don't necessarily agree with rewriting deprecated Perl routes in Go. >> I think if a route is deprecated in release N, we can remove it in >> release N+1 (next major version). We shouldn't be stuck maintaining >> useless endpoints for eternity (especially these ones which don't even >> make sense to support). If removing these deprecated endpoints before >> API 2.x is going to break any users out there, I would be glad to hear >> out their valid use cases for having us support them. >> >> Another example is the `cdns/:name/configs/routing` endpoint. It was a >> half-implemented attempt at breaking up the CRConfig and was not >> returning any valid or useful data at all when I last looked into it. >> Just because it exists in the Perl does not mean we should have to >> take it with us to Go. And the `cachegroup_fallbacks` endpoints, which >> are now supported in cachegroups proper. And the `/riak/stats` >> endpoint, which was mainly for triage purposes during the integration >> of Riak for Traffic Vault. We don't really have a good reason to keep >> those endpoints around IMO. >> >> - Rawlin >> >
