Do you live in the now or keep a foot back in the past? Better yet, what should an API provider do?
At the end of July Last.fm shut off some old API calls, to the disappointment of some mashup users and developers (our Last.fm API profile). The company had some good reasons, but it raises the question about what developers should expect, especially from free APIs.
While the changes were announced in March, giving plenty of warning to developers, it is inevitable that some mashups wouldn’t be fixed. Indeed, there are a host of applications that can no longer be written using the Last.fm API.
Carson Ball explains one way the change is noticed by users:
“The changes that Last.fm made were not backwards compatible and caused software that used the API to break. The open source music player Banshee for instance still displays recommended tracks from Last.fm, but is unable to play these tracks. When a user attempts to listen to a recommended track, he or she is greeted with the message ‘GStreamer resource error: NotFound’ on the terminal or in the error log. In light of this error, displaying the tracks at all is rather pointless.”
In this case, it seems Last.fm had good reason to make the change. The streaming API was never documented or released, though the company did not stop it from being developed upon. Since copyrighted music is played through the undocumented API, Last.fm still had to pay for what developers used. There were real business and legal reasons for the API change.
Mature APIs like the Salesforce.com API, eBay API, and the Amazon Product API go to great lengths to address this issue via processes such as consistent release cycles and/or maintaining availability of old versions for long periods of time, even years.
Do you think APIs should always be backwards compatible? What’s the best approach when something needs to change?
Related ProgrammableWeb Resources
Sponsored by
Related posts: