As I assume is the case for most developers of mobile apps, we spend a lot of our development time working with 3rd-party API’s. I know with my apps I use API’s from FourSquare, YouTube, the FAA, Bitly, Groupon, the NY Times and Sunlight Labs among others.
One of my Windows Phone apps – AirportStatus – uses the Bing Instant Answers API to provide flight status information. Errr… it used to, before Bing discontinued the Instant Answers API on December 9th.
And the timing couldn’t be worse. AirportStatus was recently named a winner in Microsoft’s “Your App Here” contest, meaning it was awarded a 1,000,000 impression ad campaign across the MSN websites during December as well as featured placement in the Marketplace on December 22nd.
So problem #1 for me is anyone that downloads AirportStatus is going to end up with only a partially-functioning app, and probably a diminished view both of the Windows Phone platform (“hey, I downloaded this app because of a Microsoft ad on MSN”), and me as an app developer.
Problem #2 is that once (if) I can find a replacement service to provide flight data for AirportStatus (Bing’s API was free, while other services are not, and I would like to keep AirportStatus as a free app), it will still be a lengthy time period before I can update the app to use the new provider and another week or so to get the app update approved through the marketplace, then users will have to download the update to once again have a working version of AirportStatus.
The big lesson here for mobile app developers is that you have to build your own services on top of any 3rd-party API you use. I started learning this lesson a while ago, but hadn’t yet implemented my own service for the flight status data. The drawbacks to doing this are obvious – a performance hit by adding another layer to your data stack, as well as the additional work involved in building your own service. But I believe ultimately the benefits outweigh those drawbacks:
- Centralized data caching, reducing your overall API calls
- Simplified API access: Some 3rd-party API’s can be a bit, um, painful to work with. Building your own service layer on top can make things easier on the clients you are building
- If you are doing cross-platform development (WP7, iOs, Android, etc), the benefit of simplified API access really comes into play
- If a provider changes (or heaven forbid) discontinues an API you can have your apps working quicker and w/o requiring the user to download an update just by updating your service
Have you had an experience where a 3rd-party API change broker your app? Let me know how you handled it or how you architect your apps to plan for possible 3rd-party API changes in the comments below.
andrewlong.com, LLC 
Yes. My app was put out of commission by Microsoft’s decision to terminate the Instant Answer component of the Bing API. It too, was a flight tracking app. I suspect that Instant Answers was discontinued due to possible licensing agreement violations with companies such as flightstats.com and not due to relative under-use compared to other components of the Bing API (as claimed by Microsoft). Paying for a service really isn’t a realistic option for me as my app was only a buck and my expenses for a service could easily eat all potential profits. So, unless the pricing for these services dips below the stratosphere, my app is history. The other option is to go directly to the same data sources used by companies such as flightstats.com and create my own data warehouse. For a smart phone app, this would be nuts.