Yes, the versioning wasn't consistent because we switched out the database to Postgres which had several impacts to the API. The issue with API routes being too granular in the versioning is tricky because the consumers of the API will need to change as the versions of Traffic Ops moves forward. Now that we are on Postgres we plan on a new versioning scheme with /api/v2/* which we will shortly introduce. The goal with /api/v2 will be to keep the response format the same, with the intention of deprecating the /api/1.x routes.
Another goal we have is to build an API test tool (now that more CRUD routes are available), which will help with consistency in the API as well as help us with regression testing (more to come on this front). -Dewayne On Mon, Mar 20, 2017 at 11:20 AM, Hank Beatty <[email protected]> wrote: > I recently ran into an issue where one of my scripts that uses the TO API > stopped working correctly. It was failing in such a way that if I had not > been in there updating something else I never would have known it was not > working correctly. This failure was due to a change in the TO API version > 1.2. I wrote the script using version 1.2 and the version I'm testing > against now is also 1.2. > > I would like to suggest that we chose a versioning philosophy for the TO > API. The site http://semver.org/ offers a good philosophy to follow. This > also happens to be the one ATS uses. > > Let's please choose a versioning philosophy so that issues like the one I > describe above can be avoided. > > Thanks, > Hank >
