A quick google reveals the following answer…
But to myself and many others, this is far to vague-er a definition to understand their use-cases for us data analysts.
Searching for what API actually stands for doesn’t really clear anything up either (Application Programming Interface for anyone interested).
So i’m going to try and help clear things up by creating a ‘lehmans’ definition for us data analysts, alongside an example use-case from the API made available by Transport for London (TFL), https://api.tfl.gov.uk/.
So what do I think API’s are?
Well, to me, they represent the ability for us to query an online datasource by passing information (or parameters) into a URL.
Once we make our request, by pressing enter, we will be passed a resulting string of text, usually maintained in either an XML or JSON format.
This is always the first place to start. This will allow you to understand what data is available, what parameters you can pass into the query, how the query should be formatted, and the output type.
Lets have a look at the API documentation available on the TFL site.
1st things first, most APIs will require you to register your ‘app’, this is so they can. It also allows them to control the number of requests you make, most will have some sort of limit per minute/hour/day.
The 2nd thing to notice is that most API’s will actually contain a number of different ways in which you can query the database, each query will bring back a different set of information and are designed to answer the array of different questions that users may have.
It is entirely possible to use the results from one request to drive a follow up request, for example with the https://dev.twitter.com/ API, you can make one query to return a list of ID’s of all of your followers, you can use these follower ID’s to make a query against the user lookup API to return further information about each of your followers.
So give me an example.