On Thu, Aug 15, 2019 at 1:36 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.
Let's not let this thread devolve into API versioning. We should be able to make exceptions to "the rules" in exceptional cases. Deleting useless routes that provide no purpose to the system is what I would consider an exceptional case. We should support API promises where they make sense and not get too carried away with the "rules" where it doesn't make sense. At the end of the day we need to remove footguns and evolve the API. Those are things that should benefit the project as a whole, and I see no benefit in aimlessly following "the rules" where it doesn't make sense to. - Rawlin
