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 <rawlin.pet...@gmail.com>
wrote:
> On Thu, Aug 15, 2019 at 1:01 PM Robert Butts <r...@apache.org> 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
>
