It’s the sentence that no development team wants to see from their integration partners: “We are having to make changes to our API, and unfortunately these changes are breaking changes. You will have to respond to these changes on your end before the end of the month in order not to lose access.” So, breaking changes - what are they and how often do they happen?
When it comes to APIs, a breaking change is any change that is made to API infrastructure that causes connected parties to lose part, or all, functionality unless they make modifications to their API connections. And how often does this happen?
Well, the answer to this question mainly depends on who you are connected to; some companies make a lot of breaking changes due to the nature of their business and IT infrastructure, whereas other businesses might rarely have the need to make breaking changes. In our experience, most machine data APIs experience at least one, if not two, breaking changes per year.
It is important to note that not all breaking changes are caused by changes made to an API. OEMs releasing new equipment, new in-cab monitors for existing equipment, or major firmware updates for existing monitors can all cause breaking changes, and have to be taken into account when estimating the amount of ongoing maintenance needed to existing API connections.
If you are an existing Leaf client however you might not even be aware of these breaking changes, as this is something that Leaf takes care of on behalf of all clients. We update the API connection with our connected data providers when a breaking change occurs, without having to make any changes to the API interface for our clients.
This year alone we have responded to nine breaking changes from partner companies already without causing any disruption to, or development work for, our clients. This might not sound like much, but some of these changes can take an average-sized development squad more than 2 weeks to respond to; surely enough to derail most technical roadmaps!
From Planet deprecating PSOrthoTile to Trimble introducing new TMX monitors and moving to a completely new version of their API or John Deere’s new Paging Parameters and moving to the new G5 displays - our clients never noticed a thing. We constantly tell our clients that we take care of this technical burden for them, but I understand that it is hard to see the benefit when you’re not aware of all the work that happens in the background. Not having to spend all those technical resources on maintaining backend infrastructure however, makes a big difference to Leaf clients.
Breaking changes are not often a big consideration when companies decide how to connect to APIs and whether to connect with partners directly or through a unified API such as Leaf, but I certainly think it should be. Instead of just looking at the initial benefits of using Leaf, however sizable it already is, keeping the ongoing costs and inconveniences in mind makes the case for a unified API even more compelling!
Get a demo