Hey guys.
In the previous lessons, we learned all about Application Programming Interfaces, otherwise known
as APIs.
In this module, we're going to learn how to build our own APIs from scratch so that you can get a good
overview of the entire process.
In the previous Capstone project, I showed you a list of public APIs.
So these are APIs that anyone can access as long as you have signed up or you have the correct credentials.
Some of them are paid, and some of them are free, but they're available to anyone on the Internet.
So this list encompasses pretty much every single topic, anywhere from Health, to Pets to Public infrastructure.
And I'm sure you had a good look through it in order to choose the one you wanted to use for your capstone
project.
The reason why we use APIs is because they make development so much faster.
Instead of building out everything from scratch and collecting data, cleaning data or building up services,
you can leverage other people's existing data, their services or their algorithms in order to build
a product on top of that existing API.
So you could go from 0 to 1 in the space of minutes rather than years.
Now a really good resource I recommend checking out is Rapid API.
They're a company that collates and allows people to host APIs that customers or clients can consume
from. Being able to do that, being able to cut down your development time and to leverage other people's
work or data, is a really valuable service.
So that's why people often charge for it.
And this website, Rapid API, is kind of like the Amazon for these paid APIs.
They have free APIs as well, but it's mostly APIs that are developed by developers like you.
And then they're hosted onto this website,
and anyone who needs to use that website, for example, if you wanted to translate texts or get hold
of basketball data, then they can use these APIs and pay according to how many requests they make.
Now, Rapid API also has free APIs that can be used for developers,
so take a look and explore this website and see that if you were to create your own API hub, what it
is that you could do on here.
Now what is it that makes an API monetizable?
What makes it valuable enough for you to be able to list on Rapid API and for people to start paying
you to use those APIs?
I've kind of broadly thought about it in three categories.
One is if you have a large and valuable data collection.
Two is if you have a proprietary algorithm or a really useful service that people can tap into using
your API.
And three, if you simply just have a more simplified interface, a simplified API for people to be
able to work with something else, be it a real world service or another API.
What are some examples of that?
Let's say you had a large collection, you had over a thousand recipes for pasta and your granny gave
this to you.
It's an heirloom and you've just kept it in a file all of this time,
and today you decide to type it all up and make it available via an API.
Well, that's probably valuable to somebody out there if they're building a recipe app or if they're
building some sort of application that needs that data.
Now, on a more complex level, maybe you have a weather station and you can give people access to live
weather data in any location.
Well, that is also pretty useful and that's probably a lot more valuable than pasta recipes, but
it again falls into the data collection category.
Now the next one is an algorithm or a service.
So for example, let's say that you worked out anywhere on the globe,
if you were able to create an algorithm that looks at any two coordinates on the map and you would be
able to work out the direct line distance between those two points, or maybe you could work out the
distance that it takes a car to get there via the available roads.
And you have some sort of very, very clever algorithm that uses other APIs or other things to work
that out.
Maybe the Google Maps API, maybe you have some sort of satellite API that you amalgamate into one algorithm
or one service, and that is probably reasonably easy to build and it's something that would save people
a lot of time so that they don't have to build this themselves and hence it would make your API valuable.
Now on a
more larger scale and more complex version of this, would be something like ChatGPT.
It took them years and years to be able to collect all of the data from the Internet, feed it into
this large model, train it over years and years, which costs a ton of computing power and a ton of
money,
and by allowing you access to this service, then it makes sense that the developers who use this API
would have to pay for it because there's a lot of value there.
The final one is if we had a simplified interface as an API that you create.
So let's say you wanted to be able to have an API that allows you to order a pizza. So you just give
the API as input parameters, your location, and your card details, and then bam, you would have pizza
arrive at your doorstep.
Well that's a pretty valuable API, and that essentially is taking a real-world service that doesn't have
any sort of Internet enabled capabilities.
You know, the ability to order a pizza from Domino's, maybe they don't have an API, maybe they just
have a simple web-form, and you use something like Python and you cobble a whole bunch of things together
in order to enable this call-for-Pizza API.
So that would be pretty useful.
And on a more complex scale, you could maybe take some of the more large scale APIs like the Google
Maps API or the Google Sheets API, and they're all kind of complicated because they allow you to do
many, many things with that API, and with Google Sheets or with Google Maps,
but maybe you realize that in common situations people only want to do one, two or three things with it and
you simplify it down for them so that any developer can access that API and simply log some data in
a Google sheet with just a few lines of code instead of a few hundreds of lines of code.
And that again, you're saving people time.
You are making things easier for people, making things more accessible, and hence it also makes sense
that it would be a monetized API.
These are actually real-world examples. There actually is a developer who created an API called Domino's
Pizza API and it is a NodeJS API.
So that means you'll be able to look through the code and you should be able to understand some of the
code to see how they actually created this API because it's open source on GitHub and all you have to
do is search for Domino's Pizza API, plus the word GitHub and you'll be able to find this code base
and see this API being built in real life.
Now this is an open API, so it's free to use and open to the public.
But equally likely, this could have been an API that's hosted on Rapid API, in which case we wouldn't
be able to see the source code so that other people don't just simply clone your code and take what
you've developed.
Another category of APIs are internal APIs.
We've talked a lot about external or rather public APIs, so these are available for anybody should
they wish to pay or should they wish to sign up to use this API.
But there is also another category of internal APIs.
Let's say you work at a company, right?
And you need to keep track of all of your inventory.
You have a whole bunch of things.
Let's say you are Amazon, and you have all of these items in your warehouse and you need to be able to
keep track of them.
Or if you are a company selling encyclopedias door to door, then you would need to know, well, how
many of these encyclopedias have been sold and how many do we have left to sell?
This is pretty important in order for you to make sure that you never run out of encyclopedias. You
might want to know, well which addresses have been visited by your agents so you don't double up on sending
agents to the same place. You might want to submit which addresses actually bought an encyclopedia in
order to be able to analyze your data.
And we've been building internal APIs basically every single time we've built a backend because we haven't
opened that up for anyone else to use.
Now, as you realize, that doesn't mean that other people can't,
it just means it's not documented and we haven't promised to support it.
In many cases, a private or internal API is something that is not supported for external use.
But unless you have security features in place, it doesn't mean that it can't be accessed.
And in fact this is a huge category where people try to figure out what are the methods
in various companies, private APIs, which we won't go into right now,
but this is something to be aware of. Not only when you're building your own APIs, but also when you
are trying to figure something out on the Internet.
What we're going to be building in this module is a REST API.
Unfortunately, it's not time to rest, but it is a time to build what's called a Representational State
Transfer API.
Don't sleep just yet.
It's time to review what we need to do to follow the REST architecture.
So it's essentially just a bunch of rules that describe how an API should be.
Let's go.
Let's take a look.
The first rule, and this is one of those classic interview questions.
Good to keep some notes on if you're thinking about applying for jobs.
The question would be something like what makes an API RESTful?
And the number one rule for making an API RESTful is that it uses standard HTTP methods.
You're already pretty familiar with this.
It's your GET, POST, PUT, PATCH and DELETE.
And these are the standard verbs that you use to interact with our RESTful API.
So that means if you wanted to grab hold of something from the API, you would use the GET method.
If you want to delete something, you would use the delete method.
So far pretty easy.
The next rule is that it should probably have a standard data format that it responds with.
That means something like the JSON format, the JavaScript Object Notation, or something like XML.
And this is a response to calling the API and the response is given back to the client and RESTful APIs
respond with something that is pretty standard like JSON.
This is the representation part of the Representational State Transfer.
Resources are represented in a specific format like JSON, and that is sent in response to the client.
Again, so far nothing too crazy.
The next rule is that clients and servers in RESTful APIs are completely separate.
They are not on the same system or in the same file and they're able to message each other over a network.
In order to make requests and also to get back responses.
And this part of the RESTful API architecture allows each side to be able to scale independently from
each other and they can evolve and be completely built separately by different people, which means
that the RESTful API allows the whole system to scale very easily.
The next rule is Statelessness.
What this means is that each request from the client to the server should contain all the information
that's needed to understand and process the request.
So the server shouldn't be storing any sort of client side, state or client side data between the requests.
So what this means is that each single request can be completed, and each single response is also complete
without need to know what happened previously.
And this basically again allows better scalability of the API and it simplifies the server-side implementation.
So every single time the client makes a request to the server, it contains all of the information that
the server needs in order to figure out what to respond back, and the server doesn't need to check, "Oh,
what did this person ask for previously?"
Or.
"Oh, uh, last time I sent them the fourth item,
so if they're requesting now, they must want the fifth item."
That means that you need to keep track of state
and it means that if you have multiple clients coming in, it can quickly reduce your efficiency and
scalability of your API.
This rule basically allows the server to serve many, many clients and many, many requests.
Next is that your REST, the API is resource-based, so it is an API that is centered around resources and
uses a Unique Resource Identifier, also known as a Resource Locator,
so this is a URI,
or a URL,
in order to locate specific resources.
We all know what a URL is because you use it every single time you try to access a website,
but know that a Universal Resource Locator, is simply just an address for a particular resource, and it's
a type of a Universal Resource Identifier.
It identifies that resource in the API.
You might have seen all these five rules and thought to yourself, "Hmm, this seems kind of familiar.
A lot of this just seems like it's the internet."
Well, if that is true, then you are very much on track because the Internet as you know it, the World
Wide Web is considered one of the most successful implementations of RESTful architecture, because we
have our resources located in URLs.
So this is how we can identify what it is we want to access.
We work and interact with the server through an API using HTTP standard protocol, and the responses
we get back are standard data formats such as JSON or XML, or JavaScript, or HTML
and also we have a strict client / server separation.
So the client is the person who's using the browser and the server is the computer that holds all of
the data that is needed to be served when somebody requests a particular web page.
And finally, the Internet is pretty much Stateless.
Every single request to a web page contains all of the information that's required in order to determine
what web page to send back.
This is also why we're learning to create RESTful APIs, because it is a key concept in web development
and because we're learning to become web developers, then it's pretty important that we get our heads
around how to build RESTful APIs.
The API that we're going to be building is a joke API.
It's a RESTful API abiding by all of the rules that we talked about, and it serves up jokes to anyone
who wants to access that API.
Maybe you're a pretty good joke writer and you've written, let's say, a hundred good jokes and you've
categorized them into different types, different categories, and you allow anybody to be able to tap
into your API and get hold of some jokes.
This is going to allow us to see how everything works in practice by building this API from scratch.
Once you're ready, let's get started.