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 <ocket8...@gmail.com> 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 <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
>>
>

Reply via email to