How sensible is it to build a website/app etc. using an external api?

Question

Wanting to expand my programming horizons I recently started building a website.

I have started to build up my website and it is heavily focused around an external api.

The reason for using this api is that I could not get all the information it provides by huge huge margin.

I am making a video games site where users can comment on games so I want to be able for users to find all there favourite games on the site to talk about, now as well as just titles it contains so much great information about a game, websites, developers, released dates, screenshots, reviews, trailers,.... the list goes on. I could never ever bring this much information together.

It is built by a community of hundreds if not thousands of people contributing to the information.

Now you understand that this api is crucial to my site.

As this is an experimental site for my education only it doesn't matter really matter but I did wonder if it is "good practise"/"smart" to do things like this.

The reason I am thinking this is that if the owners of the site decide to kill the api or not allow it to be updated then my site would become worthless! even the owners could change the licensing on how it can be used etc.

Of course when it is purely for my own experience it wouldn't be a major deal but what about if you spent a lot of time on your site and you had a lot of users.

It seems to me like this might be a recipe for disaster to have your website based around something that is out of your control, on the other hand it seems like there are some fantastic api's out there that you could not source the information they provide even if you wanted to so why not take full advantage?

Answer 1

You've really named all the pros and cons, yourself. And the answer really is: It depends. In the end it comes down to these questions that you will have to answer on a case-by-case basis:

1. Is there any realistic option to achieve what you are doing without a dependency outside your direct control? Apparently, in your case the answer is: no.
2. How likely does it seem for the external API to go away?
3. How catastrophic will it be, if the external API goes away?
4. Are there any fallback options? Does another provider offer a similar API / similar data?

Esp. 4) will be something to consider, early. If you build an abstraction layer that works across different providers (as also suggested in John Wu's comment), that will offer you substantial protection both against incompatible API changes, as well as the complete removal of an external API. Note that this may also mean omitting certain features that are available at a single provider, only.

Answer 2

Relying on an API is indeed a serious choice to make. In general, when deciding that a project will rely on an API, one would do the following:

• Ensure the API won't change “just because the author of the API decided to change it.” In other words, the API should ideally be produced by a solid company which provides enough support for the API, and knows how to decommission the APIs properly.

  An API by Google or by Amazon is a good example of an ideal API. You are pretty sure that the API won't vanish, and will be decommissioned according to a plan. You are sure to be informed about the plan months in advance, in order to be able to change your code accordingly.

  An inverse example is an API created by an unknown programmer for his personal needs. You have absolutely no idea what would happen with the API. The programmer may decide to change it or remove it, or there can be technical problems which would make it impossible for you to access the API for hours, days or months.

• Isolate the API from your application and make it easy to swap the API for something else.

  Imagine that you're relying on a third-party API to do something very specific: get exchange rates, store BLOBs, get weather forecast for the next four days. If you know that the API will be decommissioned, no big deal, you find another API and change only the implementation, without changing the interface and without impacting your application.

  The inverse example would be an API which traverses your whole application, which could happen when your app was built in the first place around the API or with this specific API in mind. You cannot imagine moving to another API, because this would mean rewriting practically the whole application, since the current architecture wouldn't fit a different API.

  You may find it by looking at the tests of your application. Does it look like the stubs of the API are inspired by the exact architecture of the API itself? Or are they neutral, i.e. don't show anything about the actual specifics of a precise API?

  If comparison may be permitted, the second case is generally what happens when the application is built on a given framework, for instance SharePoint. If the application is designed as a SharePoint application, the day where it should be ported to another framework, there is nothing to do: it should be thrown away and rewritten.

The way you phrased your question makes me think that for the both points above, your project is not going well. The fact that you're asking yourself what would happen “if the owners of the site decide to kill the api or not allow it to be updated” seems to show that the API is not pretty solid. I mean, one wouldn't wonder too much what would happen if Twilio or Amazon S3 disappears. Similarly, the fact that your application “is heavily focused around an external API” seems to show that you built it like a SharePoint programmer builds a SharePoint app. If Twilio bankrupts, one can always move to Amazon SNS, and if Amazon decides to close S3, one can move to Azure BLOB Storage.

This doesn't mean you did a bad thing. You wrote your app in order to learn, so it's not like your app is used by thousands of corporations which trust you for providing a reliable service. And sometimes it makes perfect sense to build a website around an API, with the expectancy that once the API would change, the website will stop working. Nothing wrong with that.