Programming Interface Changes - the Real Cost

May 9, 2020      .net Programming, Application Integration, General Business

Products that offer API (Application Programming Interface) access are wonderful. They allow a published method of getting information out of (and usually modifying existing information). This sure beats the “hackery” that has been done in the past like directly reading a database or running a scheduled data dump. But what happens when the publisher of the API changes it with little notice and virtually no documentation? As programmers, we need to be wary of this…

This recently happened when a client of mine performed a routine upgrade on their large line-of-business application. I had written a bunch of code to do some custom reporting that was really helping things run more efficiently and accurately for them. Then, suddenly – boom! – what I wrote stopped working.

It took a day or two to notice and once they did, I was contacted. My first question, “did that system get upgraded”? Oh yeah, was their reply, over the weekend. Ah ha! That explains why code that had been running for months suddenly stopped working.

After digging through logs, I discovered that API calls were no longer supported in the format I was calling them. That’s odd I thought, because I’m using the published specification and even code to call the API that the vendor provided. More digging revealed that this vendor had updated their API to a new version and apparently disabled all support of past versions without telling anyone – nice…

So, I was forced to update all the code I had written to this new version. What started as a series of 125 compile errors became working code in a matter of several hours. Except for one bug that this new API version introduced that forced a trouble ticket to be opened with the vendor.

Needless to say, my client is happy to have this code working again but was not at all pleased to have to spend money on me fixing what was a perfectly running solution because of an undocumented and, more importantly, unwanted API version upgrade.

Forward momentum is great – until it isn’t. In this case, the API version update offered very little benefit due to virtually no new features but resulted in a ton of headaches and some unwarranted expense.

The lesson from all this: as programmers, we need to be cognizant of the cost of moving forward. Things can never stand still, but progress needs to be made in ways that are not harmful to existing installations.