Hey all,
I believe I’ve found an obsolete/broken API endpoint [1] that might be a good
candidate for removal. Here is an example request:
GET /api/1.2/cdns/mycdn/configs/routing
This will return a json object that looks like the following:
{
“response”: {
“trafficServers”: […],
“stats”: {…},
“cacheGroups”: […],
“config”: {…},
“trafficMonitors”: […],
“trafficRouters”: […]
}
}
As you might notice, this looks very similar to CRConfig.json except that most
of the keys are named differently (e.g. “trafficRouters” vs. “contentRouters”).
There is a lot of overlapping information between this and CRConfig which makes
me believe that perhaps this API was a precursor to CRConfig that is now
obsolete. Further evidence that it’s out-of-date includes (among other things)
missing “httpsPort” fields in the objects and empty “deliveryServices” arrays
for every “trafficServer” object (the arrays shouldn’t be empty if there are
delivery services assigned). Also, it seems to be targeted for Traffic Router
usage, but Traffic Routers currently pull their CRConfig from Traffic Monitors.
The following API endpoints [2][3] seem to provide more up-to-date information
via CRConfig and should already replace the outdated endpoint above:
GET /api/1.2/cdns/mycdn/snapshot
GET /genfiles/view/bycdnname/mycdn/CRConfig.json
I propose that we remove this API endpoint [1] unless someone can verify that
it’s still in use somewhere (with a good reason to not use a CRConfig endpoint
instead). I will wait a few days for responses before starting on a Pull
Request to remove it.
Thanks,
Rawlin Peters
[1]
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L469
[2]
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L439
[3]
https://github.com/apache/incubator-trafficcontrol/blob/master/traffic_ops/app/lib/TrafficOpsRoutes.pm#L331
