+1 to deprecating servers/totals @ michael - can you add to your deprecation list?
On Thu, Dec 12, 2019 at 3:11 PM Rawlin Peters <[email protected]> wrote: > +1 on deprecating `servers/totals` also. If a client needs the totals > of each type of server, it's simple enough to ` GET /servers` and > count the types client-side. > > - Rawlin > > On Thu, Dec 12, 2019 at 2:47 PM Jackie Zimmat <[email protected]> > wrote: > > > > I would like to propose that we deprecate `servers/totals` also. > > > > > > It does not seem like this endpoint is used anywhere or that it is very > > useful. > > > > It seems like the data could be gathered elsewhere. > > > > > > > > On 2019/12/10 16:25:41, Rawlin Peters <[email protected]> wrote: > > > > > I don't think we plan to support 2 major versions of the API at all > > > > > times. I thought we were only supporting 2 major TO API versions for > > > > > one major release period (e.g. 4.x supports TO API 1.x and 2.x, once > > > > > we release 5.0 it would only support 2.x). > > > > > > > > > > However, we _do_ support the latest minor version of the last two > > > > > major TC releases (currently 2.2 and 3.1?). Once we release 4.0 we > > > > > will no longer support 2.2. > > > > > > > > > > - Rawlin > > > > > > > > > > On Tue, Dec 10, 2019 at 8:13 AM Jeremy Mitchell <[email protected] > > > > wrote: > > > > > > > > > > > > +1 to that deprecation list. Just to clarify, those endpoints will > > continue > > > > > > to function in 1.x and since it sounds like we plan to always > support 2 > > > > > > major versions of the api, they will continue to function until we > get > > to > > > > > > api 3.x which seems like ample time for clients to pivot. > > > > > > > > > > > > Jeremy > > > > > > > > > > > > On Mon, Dec 9, 2019 at 4:36 PM ocket 8888 <[email protected]> > wrote: > > > > > > > > > > > > > +1 on that list > > > > > > > > > > > > > > It's not enumerated in the docs which endpoints will and won't > return > > > > > > > alerts - and everything returns alerts on errors - so clients are > > advised > > > > > > > that any payload could have them. tl;dr I don't think adding alerts > > should > > > > > > > cause a problem for compliant clients. > > > > > > > > > > > > > > On Mon, Dec 9, 2019, 10:09 Rawlin Peters <[email protected]> > wrote: > > > > > > > > > > > > > > > Having been a part of that working group discussion, I'm +1 on > this > > > > > > > > list. I'd add that there might be some endpoints that don't > > currently > > > > > > > > return an `alerts` array in the response, so adding a deprecation > > > > > > > > alert to the actual response might not help much (because clients > > > > > > > > won't be looking for a new unknown `alerts` field). For those > kinds > > of > > > > > > > > endpoints, I think we'd be ok skipping that part (the deprecation > > list > > > > > > > > will also be in the changelog release notes). > > > > > > > > > > > > > > > > - Rawlin > > > > > > > > > > > > > > > > On Mon, Dec 9, 2019 at 7:06 AM Hoppal, Michael > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > Based on the Traffic Ops API rewrite/versioning strategy it was > > decided > > > > > > > > to promote the current Traffic Ops Golang implementation to TO > 2.0 > > > > > > > allowing > > > > > > > > us to leave behind dangerous/deprecated routes(in Perl) in 1.x. > > > > > > > > > > > > > > > > > > The routes we deprecate will have a deprecation notice added to > > the > > > > > > > > response and will be supported until TC 5.0. > > > > > > > > > > > > > > > > > > As part of the Traffic Ops working group last week we put > > together a > > > > > > > > list of routes we think should be deprecated and not carried over > > to 2.0. > > > > > > > > > > > > > > > > > > The list and reasoning why we think it should be deprecated can > > be seen > > > > > > > > at > > > > > > > > > > > > > > > > > > https://gist.github.com/mhoppa/bb5341e6a0617aea9282265b840e0735#deprecation-routes > > > > > > > > . > > > > > > > > > > > > > > > > > > These routes include: > > > > > > > > > > > > > > > > > > > > > > > > > > > * /capabilities/{{name}} > > > > > > > > > * /capabilities (Only POST, GET will be rewritten) > > > > > > > > > * /cdns/{name}/configs/routing > > > > > > > > > * /divisions/name/{{name}} > > > > > > > > > * /federation_resolvers/{{ID}} > > > > > > > > > * /hwinfo/dtdata > > > > > > > > > * /parameters/validate > > > > > > > > > * /regions/{{region}}/phys_locations > > > > > > > > > * /parameters/{{id}}/profiles > > > > > > > > > * /parameters/{{id}}/unassigned_profiles > > > > > > > > > * /divisions/{{division}}/regions > > > > > > > > > * /api_capabilities (Only POST, GET will be rewritten) > > > > > > > > > * /api_capabilities/{{id}} > > > > > > > > > * /servercheck/aadata > > > > > > > > > * /stats_summary/create (Will be rewritten to be supported > as > > a > > > > > > > POST > > > > > > > > on /stats_summary) > > > > > > > > > * /types/trimmed > > > > > > > > > * /deliveryservice_user > > > > > > > > > * /deliveryservice_user/{{DSID}}/{{userID}} > > > > > > > > > * /to_extensions/{{id}}/delete (Will be rewritten to be > > supported > > > > > > > as > > > > > > > > a DELETE on /to_extensions) > > > > > > > > > * /cachegroup_fallbacks > > > > > > > > > * /cdns/usage/overview > > > > > > > > > * /riak/stats > > > > > > > > > * /traffic_monitor/stats > > > > > > > > > * /cdns/configs > > > > > > > > > * /cachegroup/{{paramID}}/parameter > > > > > > > > > * /cachegroups/{{paramID}}/parameter/available > > > > > > > > > * /deliveryservices/{{id}}/state > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > >
