I’m currently working on building the new OpenSpending-Next API. This API will have more features than the current API, and will work on the new, more flexible, Fiscal Data-Package model.
One of issues we’re facing is for which APIs we need to maintain backward compatibility. In short, this means that for some of the current APIs, we’re going to create mocks in OpenSpending-Next. Each of these mocks will behave exactly the same as it does in the current OpenSpending - although it’ll be working on the new data model.
For obvious reasons we want to keep backward compatibility only for those APIs which are heavily used today, and removing them would require many adaptations and might cause breakage of existing websites. Those APIs which won’t be kept will eventually be shut down - meaning that anyone using them right now will have to update their code to work with the new APIs that will replace them.
Therefore, I conducted a short analysis of current usage patterns of OpenSpending - including the existing API. You can see the results here: https://gist.github.com/akariv/2e95efffc1af9bf44b09.
My conclusion from this analysis is that backward-compatibility should be maintained for the Aggregate APIs, but not for others.
I’d really love to get input from the community as well, regarding which APIs are currently being used, how they are used and for which ones do you think we should keep backward compatibility.