So like I just said, you've done an awesome thing, you have created this awesome Reddit clone called
Zap It and it's really great.
But I want to talk about the limitations and what's sort of missing here, and this will help us as
we move forward.
So if you create just an API like this, it's probably going to be pretty hard to get off the ground
like people would.
You would probably see an existing Web site that eventually offers an API option.
Right.
Like, you would build a zap it Web site in Django, have that up for a while, but then you say, hey,
I'm going to, you know, make an API so people can make their own mobile clients or something like
that.
So that's sort of thing one is, you know, how does someone understand this API?
And a big thing here is I think really, if you're going to have an API that's out for the public to
use, you've got to have some sort of documentation that lists, you know, information about the API
so they know what to expect.
Now, the Jenko rest framework gives you a lot of good information, like if someone comes to, you
know, this page, The Post, Lyssa says, oh, look, I can do aget or a posten.
You know, as they move different places, they can see that.
But it's still not enough, in my opinion.
I think it's better to have some logit documentation.
Remember when we looked at the Twitter documentation like wuv, they really talked about everything.
The next step here is that there is no way via the API for us to be able to log in or sign up for an
account via the API.
Right.
So if you imagine someone was making a mobile app for our Zap It service and they were going to, you
know, let people make accounts on the, you know, the mobile app.
We don't have anything in place for that.
We don't have anything in place if someone wants to log in.
Now, technically, we do have a way for users to make those requests without being signed in, because
everything that's happening via the sign in is currently happening visually here inside of the browser.
But you'll notice, for example, let's say that I want to, you know, go ahead and like create a post
and I want to do this via Curl.
So this is where I talked about, you know, having your own rest client vs., you know, Kerl it's
going to be a lot more convenient with the rest of rest client.
In fact, I went ahead and made one via one of my programs and then just copied the code to a kernel
command.
This is essentially what we'd have to type into the terminal in order to get this to work.
So you can go ahead and do the same thing.
Basically with Kerl, we're saying, okay, you know, the really basic one when we just do a get for
you URL, we don't have to do any of the special stuff.
But if we're doing a post we have to do the dash capital X.
That's a post in because we're passing it, Jason.
We have to say, you know, this has a content type of Jason because we have a user that this is where
I'm showing you.
You can't log in via this API.
But if I pass in that the user is zappy code and the password is this and then I pass forward the data
like, you know, this is the title and this is the euro.
If I have all of this when I go ahead and copy this and I come to my terminal, make sure your servers
running.
But in a separate terminal tab, I'm going to paste in all this Kerl thing and go ahead and hit enter
in on this.
It's going to make an object like.
So that part of the API is functional.
And if we go ahead and, you know, go back to the post lists here, you can see, oh, look at, you
know, just added what we created here.
But at least in my opinion, this isn't really ideal in this also.
What I'm talking about, the limitations of the API and what we have here.
These are going to be addressed in the next section.
In the next section.
I have an existing project.
It's a an app that's a to do list.
I call it to do.
This is from my Django three course.
And I'm going to give you this completely ready to go.
Web site that's made in Django but has zero API.
And then we're going to fill in the API for that site.
And we're going to address things like, you know, letting people sign up for the service via the API.
Being able to log in and using something called authentication tokens so that when they're making requests,
we don't have to always pass in the username and password.
Like, at least in my opinion, I think it's really bad API design.
If we have to always be passing the username and the password inside of that request, like, you know,
if everything's over H TDP s and the, you know, developers really secure with how they store that
password.
That's probably OK.
But a much better solution is have you know if the user enters in their username and password, send
that over to the API, get an authentication token and then just have to store that token, which can
be destroyed or updated at any point.
We'll talk about that in the next section.
But basically wanted to say EFF gone on pretty long here.
Congratulations on making your very first API.
Hopefully the sparks.
Some imagination you to think, you know, how can I apply this in my projects?
But, you know, I think it's really going to become valuable here as we move into the next section
and talk about, you know, how we apply this to an existing project, because I'm guessing most of
the time that's going to be your situation.
Not always the case.
There's a lot of front end frameworks where if you just create a rest API, you can build all your Web
site visual things over that API so that, you know, your Web site is essentially a client, just like
a Web app or a mobile app might be a client or a desktop app or whatever it is.
But this next section, I think, is to really take things to the next level for you.
So without further ado, let's jump to the next section.