During the last 5 years or so I have had several ideas about building some products around public API’s. However, I needed to hold my horses because by building around a public API, I am probably not creating value for my company or product. Most services/sites that have public API’s, allow the usage because it helps them to grow when independent developers innovate and create with their product.
The more developers embrace and create web and mobile apps with the API, the more exposure and publicity the service gets in the media. For example, you could not talk about TwitPic without mentioning Twitter because the TwitPic depends on Twitter. The issue I have with those API’s is that I see a common patterns from the publishers that makes me wonder if it is worth investing resources in them. The following are the 3 reasons I personally have to avoid using public API’s.
Closing or Canceling the Service
It is not a secret that Yahoo builds or acquires a lot of services and then closes them. It would be painful to depend on one of those products especially when your whole application is built around that particular product. One day, the term of services of the application may change and you are left behind and forced to close. An example of this is Netflix shut down their public API for good in November 2014. So, after you spent all that time developing a fancy app that displays information about movies or suggest what movies to watch, the apps are not going to work. The cost of having a database with all the information may be too high for a single developer or small team to implement. If you want to look for more examples just look for the “Spring Cleaning” of some Google API’s in 2011.
The API is not Yours
We have to understand that we cannot control anything about the API. It is rare, but the service may be down and there is nothing you can do about it. It is not that you can order your team to investigate and solve the issue or check what went wrong. The only thing we can do is wait until the service finds and fixes the problem. But, meanwhile, you will have to deal with the complaints, emails, and social media posts that criticise your application publicly because it is not working.
Taking your Idea and Improving their Own Product
Let’s go back to TwitPic. TwitPic was born in 2008 from the need of sharing images on Twitter. This application helped Twitter to become popular and useful because users were able to share pictures online as photojournalists. In fact, in 2011, 45.7% of the images shared on Twitter were uploaded via TwitPic. But, in the same year, Twitter rolls out with a new feature. The new feature is just a photo sharing in Tweets which make Photo Sharing services useless. Moreover, after the photo sharing apps created value for Twitter and helped it grow, they were left behind and forced to close due to legal threats and Twitter dropping support for those third party apps. Something similar may happen with Timehop because Facebook just released a similar feature with Facebook Memories.
Conclusion
I am not saying that you cannot develop your application using external API’s. In fact, in the future I will make another post about the reasons to build around a Public API.
The real issue is creating an application where the core components depend on external API’s because you are not really creating something unique that will last. You are extending the functionality and adding value to the API, and later they will replace your idea with theirs.