All right guys.
Welcome back.
In this module we're going to talk all about a prize or other application programming interfaces.
Now it's very likely that you would have come across this term of ready people talk about APC's for
there is an API for that.
But what exactly is an API anyways.
Well here's a good definition.
So an application programming interface is a set of commands functions protocols and objects that programs
can use to create software or interact with an external system.
Now it provides developers with standard commands for performing common operations so they don't have
to write the code from scratch.
Now this is a very very broad definition and there's also a lot of components to it.
So in this lesson I'm going to break this down and try to explain.
All of the different parts of an API and how it works in practice.
So if we take that first part which is a set of commands functions protocols and object that programmers
can use to create software.
Well if you think about that we've actually already used an API.
Right.
Jay queery basically had a whole bunch of functions and methods that allowed us to create software.
And it made it so much quicker to perform a whole bunch of things using javascript in the dorm by using
these special methods.
So this is a form of API that developers use to create software.
So for example for those you guys who are on the iPhone or Android development tracks then you'll know
that to develop an ISIS or an Android app we're using the API that Apple has provided or that Google
has provided in order to interact with the IRS or the Android operating systems.
And this is essentially code that somebody else has written for you to interact with the hardware and
you can use it by looking through the documentation and calling some of these methods.
Now that's a very common form of API.
And in fact whenever we're creating a Web site or an app or any sort of software we're essentially using
these types of API.
But in this model the type of API I want to focus on and what people tend to mean when they talk about
API eyes or API eyes that are use to interact with an external system.
So for example if you take a look at the tender app and if you scroll down on somebody's profile you'll
see that there's a section for Shadd friends and shared interests.
Now where does this information come from.
Well doesn't come from tinder.
In fact it comes from Facebook.
So when you sign up to Tinder which is this dating app essentially if you're not familiar with it then
it asks you to log in via Facebook.
So now Tinder has your Facebook log in details and it's able to go to Facebook servers and interact
with Facebook in order to bring all of this information back into the tender app.
So we'll look at who are your friends and look at what are the things that you've liked in the past
and will use that information to populate these sections in the tinder app.
Now up till now our Web sites have only really been able to make requests to our server.
And these are get requests and in return our server sends back a response.
And that includes all of the H.M.S. access javascript files that requires in order to render a Web site.
Now what if for our Web site we wanted information from Facebook's servers.
Well in that case what we actually need to do is we need to make a request to somebody else's server.
So a Facebook server from our server.
Now this could be a get request for example say we have a Web site which is a dating Web site that matches
people up by the things that they've liked on Facebook.
Then we need the data from Facebook in order to do this.
So we can make a get request from our server to somebody else's server.
Well in this case it's Facebook's server and Facebook will send a response back with all of that data
that we need in order to populate our website.
And this is one of the most common ways of using a prize which is to interact with an external source.
Now when we are doing this we can't just willy nilly go into somebody else's server and make a request.
Now we have to do it through the API the application programming interface and this interface will determine
what all the things that we can request from their server and how should we do it.
So it's kind of almost a bit like a menu if you will.
Right.
For example if we were trying to tap into the API of a website that has data on crypto currencies then
that API menu might include things like well you get the price of bitcoin you get the price of a theory.
You get the price of other crypto currencies and we can choose based off this menu or this API documentation
what it is that we can do to interact with this other person's server.
So let's take a look at this in practice.
Now over here I've got the Web site which is one of the largest or as they say one of the oldest sources
of Bitcoin data and we can go over to their API is by going to this dropdown list and going to the documentation.
Now the documentation describes how you can interact with this particular API with this particular Web
site.
So for example say if we wanted price data for say Bitcoin right.
Or they tell you this is how you can get price data for a specified symbol which is basically a crypto
currency.
And this is how you structure the HTP request.
This is the base you all read that you have to go to and then you specify a pair of symbols.
So for example how much does one bitcoin cost in U.S. dollars.
And on the right they've actually created an example request fee so you can test out this API and you
can see that the first key word that they're using is something called Kerl.
Now curl is a way of making an HTP request through the command line.
And if you have a look on this website I've included a link to it in the lesson resources you can see
that curl is simply a client for you are Elle's or it's simply a way for you to interact whether you
are ill on the command line and it's almost easier if you pronounce it as see you Aurel to understand
exactly what it does.
So let's give it a go.
So if you open up hyper and you type Kerl remember that every time you type a new command you can first
write man in front of it.
So Mankell and this when you hit enter will give you the manual for this particular command.
So it has a description and it has a whole bunch of things that you can do.
It's basically a copy of this website but it's useful when you're dealing with a new command line command
that you've never seen before just typing man in front of it can give you a big hint as to what you
can do now to quit.
Simply type q and you exit that command and we can clear our terminal.
So now if I wanted to see you all roll of Google then I can type CRL H-D's U.P.S. Doug Google dot com.
Now this basically makes a simple request to the servers of Google dot com and it will send back the
response which is all of this.
Now if you actually take a look at this closely you can see it's simply the HTML that your browser would
render.
For example if you tried to go to Google dot com.
Now I'm pasting it here in atom because I can save it as a local file say Google dot h DML.
Now atom will recognize an HMO code and I can use control option B to beautify this.
A shell code or if you can't find it just head over to package's atom beautifier.
So now it's looking like something that we're familiar with right.
It's got CSSA in there.
It's got a G-mail code in there and there's a few areas here and there.
But if we save this and we try to open up this HMO inside chrome then you can see that this is basically
just the Google page right.
And it's the same when I go through the browser although the browser is obviously a lot better at getting
back images and assets.
But this is essentially what we get back from our Kerl.
So now let's try and use that Tcl command to get back some data from this bitcoin average API.
And if we copy and paste this into our terminal maybe it's worth clearing our terminal first to get
rid of all of that junk and paste in this example request that they've supplied for us.
This basically gets the Tica data for BTC to USD conversion at the current moment.
So when I hit enter I get some data back and this data is structured in a format called Jason now we've
spoken about this briefly before but in the coming lessons we're going to be diving deep into this particular
format and we're going to see how we can use it to grab pieces of data from our API requests.
But it's pretty simple if you just take a look at it.
It's a whole bunch of key value pairs.
So for example in this case we've got the key of ask and it has an associated value of eight thousand
two hundred fifty nine.
And this if you dig through the Bitcoin average documentation will tell you that this is the current
asking price of bitcoin in U.S. dollars.
So one bitcoin is worth roughly around eight thousand two hundred dollars right now.
So that was pretty cool.
Pretty interesting.
And if we wanted to tap into one of the other routes that they have then we can simply as they say change
the currency pair.
Right.
So what if instead of BTC to USD we did fear him so ATHM to Euros or now we get back a result and it
tells us that currently by a single ether we have to pay around 500 and 80 euros.
So a lot cheaper than Bitcoin but still pretty pricey.
So that was just a really quick way of showing you how we can make requests through an API to grab data
from this Web site.
Bitcoin average dot com.
Now what we've seen so far is that there are pre-determined routes.
So this particular route has been pre-define this forward slash 88 EQR.
Now if we try to tap into a route that doesn't exist let's say today N-th to eat PH then we actually
get an error.
It says that symbol is not supported.
So this means that this route doesn't actually exist.
The servers of Bitcoin average haven't planned for you to be able to use this particular combination
of currencies and sometimes when you are using these API to get data from a nother Web site servers
you might need to provide pieces of input.
So for example what if we wanted the price of bitcoin at a particular date.
Now this is the equivalent of going to a restaurant and you're ordering something like eggs right for
your breakfast but you might want to provide a parameter say how you want your eggs done.
Do you want to scramble.
Do you want it sunny side up.
Do you want to hard boiled and in order to do this through these guys.
We have to use parameters.
Now when you look at the API dogs you'll notice that some of these requests allow you to provide a parameter
or an input.
Now if we take a look at historical data because I'm interested in how much I needed to pay for Bitcoin
maybe a few years ago.
For those you guys who are doing the IRS track you will know that there is a challenge in there called
the Bitcoin ticker and this gets you to build a bitcoin app using exactly this API Bitcoin average.
Now we created that particular tutorials on time in 2015.
And I'm interested in what would have happened if I bought a whole bunch of bitcoins when I created
that Chateauroux.
So let's take a look at the historical data that we can get from this API.
So if I click on historical data you can see that there is something called price at timestamp.
So this returns a price at a specified time step in the Unix format.
So the Unix timestamp is basically the number of seconds since January the 1st 1970 and this is known
as the Unix epoch.
So this is the timestamp that a lot of Web sites and API will work with.
So lets enter a date over here to convert our normal date into a timestamp.
So I'm going to put in 2015 August the 1st and I'm going to convert to a timestamp and it tells me that
that particular date is this many seconds since January 1st 1970.
So that's the timestamp that we're going to be using.
And if we take a look back at the API for getting the price at a particular timestamp you can see that
this is the basic Yareli that we need to use and they have a whole bunch of routes for say BTC to USD
and all of the other currency pairs.
But then there's this little question mark now browsing the web you might have occasionally come across
places where you see that question mark in the you Arel up him.
Now that question POC basically shows you that everything that comes afterwards is a parameter or an
input.
So in this case the parameter name is called out and inside there we can specify the timestamp in Unix
format in order to get the historical price of bitcoins.
So let's try this let's copy this code and let's clear our terminal and paste it in here.
But we're going to change the value of that parameter.
So as we said the question mark denotes the beginning of your parameters and in a lot of API you can
add on a whole bunch of parameters say at which location and which latitude longitude and we're going
to come to see that later on in this module.
But currently we only have one input or one parameter.
It's called at.
And afterwards we have to provide the Unix timestamp which we've converted to be this many seconds.
So let's paste that in here.
And if I hit enter now I get the price of bitcoins in U.S. dollars at the historical time of August
the 1st 2015.
So you can see back then Bitcoins were only worth $283 and now they're worth something like $8000.
So I think I would have made a pretty penny if I decided to buy a whole bunch of bitcoins when we created
the first Bitcoin Chateauroux.
But it's never too late.
As they say this is definitely not investment advice.
You know listen to what I say because clearly I'm not a very good investor.
I missed out on this opportunity but I do know a thing or two about atheism.
So in this case our server is making that request to Bitcoin averages.
And in that request we packaged some parameters namely what is the time stamp that we're interested
in for the price of bitcoin.
Now when Bitcoin averages server receives that request along with the parameter input it'll be able
to look through its database and send back a response with a whole bunch of data that corresponds to
that particular date in time.
So that's how we're able to provide specific pieces of information along with our request to the API.
So as you can imagine if Bitcoin averages servers had to specify a route for every single one of these
requests then they would have to have a route for say 2018.
May the first then another route for 2018 may 2nd.
And that's just not feasible.
So instead they have a parameter that allows you to specify a time stamp that gets used in order to
search through that database to provide you the piece of data that you want.
Now for the keen eyed amongst you you might have noticed that this request looks a little bit more complicated
than the last one that we made.
What is all of these things.
Well let's see what happens when we remove it.
So let's just take this Jaro and we're going to not include this dash H and X testing testing and we're
simply going to write KEARL and this request passing in a parameter to get the historical Bitcoin price
at that timestamp.
So if I hit Enter now you'll see that I get a error and it says that I'm authenticated requests can't
access this particular endpoint.
So it's saying that you need to be authenticated with the API provider in order to try and get the historical
data.
Now why is this now if we imagine the server of these external web sites as a bank.
Right.
So they have a vault that contains precious data.
And if they have this kind of open access policy where anyone can go in them and open up the vault and
take out say 100 pounds and all they had to do was write down on a log book that said on the 25th of
November and you took out 100 pounds from the vault and that's equivalent to how we performed our first
API request when we got the current price of bitcoin in U.S. dollars this is a very trusting policy
because as you might imagine I could easily go in there and take out a thousand pounds but say that
I only took out 100.
Right.
And if I'm building my application on my website on this API provider and I'm taking out so much information
from their data servers and using up so much resources of their servers and this is completely unchecked
and unguarded then you can see that this is very much open for abuse.
So what's the solution.
Well you might need an interface so something in between you the requestor and the resource to act as
an interface that can deal with your requests.
And this is basically an analogy for our API.
Now in this bank we don't just have an open Volt's that anybody can come in and take money and just
write down what they did instead we have a bank teller and she can help and act as the interface between
us and the vault.
So for example I can say I'd like to withdraw a hundred pounds please.
And she will ask me for.
What is your password.
What is your authentication.
And I will give back a password that allows me to take out money and in the API world this is equivalent
to an API key.
And if we take a look under the authentication tab it says that the majority of our IPs are free to
use.
So that situation with the open plan bank where you just go in and you take data out of the vault but
certain end points require authentication that requires registration and the generation of an API key.
So this will identify who you are that's making these requests.
And if you keep coming in and taking lots and lots of data then they can start charging you for that
privilege.
So this is why they need an API key and authentication.
Now in our case because we're just testing the API out then we're adding this flag which basically allows
you to make a very small number of requests.
And just to test out how it works but we're not yet authenticating ourselves.
Now in addition to making get requests namely getting data from these external web sites servers we
can also make post requests where we give pieces of data to be stored in their database.
So for example in the bank scenario it be the equivalent of saying I'd like to deposit £100 into your
bank's vault please.
And this also will go through the application programming interface so that you can process your request
and add your data to that database.
Now the problem is that not all web sites work the same.
Right.
So for example you can go to the bank and you can deposit some money you can give them some data but
if you went to the police station you can't say deposit some money or you can give them pieces of data.
So different Web sites work differently.
So we now have a fuller picture of what's happening.
Effectively your server is making a request via the API or the interface to somebody else's server and
you're passing in some parameters as inputs.
And this server is interacting with their database in order to grab the relevant piece of data that
you need based off your request and your parameters.
Now once it's gotten that data then it will send it back through the response and you will end up with
that data that you wanted from their database.
And if you had any data that you wanted to deposit into their database you also have to go through the
API and their server in order to do this.
Now sometimes if you're trying to do something that is completely off the books and is not possible
for example if you went to the bank and you try to get the bank teller to do your chemistry homework
and you made a request said put his 30 first element off the periodic table then she'll say I don't
know.
And that in website terms is a 4 or 4 right.
So could not process your request basically.
So this is why we need to read the documentation every single time we use an API and some Web sites
have better documentation than others.
But if they provide a public open API they will all have documentation that tells you what you can do
how you should do it what are the parameters.
And an example or two of how you can use the API now in later lessons I'm going to be showing you a
whole bunch of other API.
But if you're interested in taking a look at what are the available API out there and then head over
to any Dasch API dot com and you can see a giant list of a whole bunch of API that you can tap into.
And by completing this module you're going to have the power and responsibility of interacting with
these API.
Now there's two tiers of API.
If you will there are API which are accessible to the public and there are some which are only accessible
internally.
So for example the Boii at the police station is able to do a lot more things at the police station
with their data then you a member of the public can.
Right.
And similarly the employees at the bank are able to tap into API that you can't.
And these are known as private API.
And these private API eyes are undocumented and not really available to the public but sometimes they
can still be accessed if you can guess the right end point.
If you can get the right parameters.
Now this is kind of equivalent to going to the bank when it's at night when all the bank tellers have
gone home and you just trying to come in and take some money from the vaults.
Now in other situations it might just be that it's a Web site that doesn't have a public API at all.
So say you know just a simple restaurant's Web sites and coming in interacting with their database through
what you might have guessed these private API.
It's kind of like robbing somebody's house.
Right.
Just going in there without permission trying to take data from their database.
Now in real life something similar happened between Instagram and a company called Follow Graham.
Now what followers did is that they somehow figured out through reverse engineering or some clever stuff
that they could access some of Instagram's private API.
So those that were only available to their internal staff to use when they're building the web sites.
And this allowed them to build features that people wanted but that were not yet available.
So for example they allowed you to have a button on your Web site say your blog or your tumbler that
allowed people to click on it to follow you on Instagram.
And this was by tapping in to Instagram's private API.
Now the result of this is Instagram basically shut them down and told them to stop using the AP eyes
and changed those private enterprise so that they couldn't get to them any more and follow Graham no
longer exists.
Now if you want to read a post by Kevin Systrom who's the founder of Instagram on why they did this
and what this was all about then take a look inside the resources of this lesson and I provided a link
to it.
But this is a common thing that you might come across private versus public API.
Now I recommend that just stick to public API which are well-documented and easy to work with and they
won't change overnight.
Because at the end of the day an open public API is basically a contract between the providers and the
developer.
And it just says here's how to interact with our system.
These are the set of rules guidelines and things that you can do.
And we promise to not change the endpoint and responses without notice.
So you can build a good product that uses our data and our infrastructure.
So that was a whirlwind tour of everything that I could possibly think about around a price.
And in the coming lessons we're going to be seeing some of these things in action and we're going to
be building web sites that use external web sites making get and post requests changing and getting
data from external sources and modifying the database of external websites.
So a lot of exciting stuff is yet to come in this module.
So later on as we revisit some of these topics and building the code around that you might find that
re watching this lecture will boost your understanding of what's going on.
So it's something that you might want to come back to in the future as well but in the next lesson we're
going to get started using and building web sites that rely on API.
So for all of that and we'll see the next lesson.