You now have Mongoose models is set up for both users and tasks.
You also know how to use those models to create new users and tasks storing them in the database.
Now we're gonna have plenty more to say about customizing Mongoose and setting up relationships between
things like users and tasks.
But for the moment we have enough Mongoose knowledge to actually start building out the TTP end points
necessary for the task application before we actually dive into writing code for these new TTP endpoints.
What I want to do is go through a quick presentation which is going to give us a brief overview of how
we'll be structuring our TTP endpoints for the task API.
And we're also going to get a sneak peek into what exactly makes up an H TTP request.
Let's jump right into that in this presentation.
We're going to cover a few different topics all directly related to the rest api but to get started
I want to define what exactly a REST API is.
Now let's break this acronym up into its component pieces right here.
That stands for the following.
So rest stands for representational state transfer and API stands for application programming interface.
Now you'll see this SHORT END TO REST API or RESTful API.
Now to get started I want to go ahead and define what exactly an application programming interface is
an API is nothing more than a set of tools that allow you to build software applications.
It is a very broad term so we could say that node provides us with API eyes.
It does things like f s enable us to build the applications we're trying to build and we could also
say that our NPM modules like express provides us with API eyes which it does express provides us with
a set of tools that allow us to build software applications.
Now in this case the rest api we're creating is also going to provide a set of tools allowing others
to build out their software.
Now let's move on to the harder thing to define a representational state transfer the rest API allows
clients such as a web application to access and manipulate resources using a set of predefined operations.
So what's a resource.
Well something like a user or a task and what's a predefined operation while a predefined operation
for users and tasks could be something like the ability to create a new task or to mark a task as complete
or to do something a bit more advanced like upload a profile picture for your user account.
So these pre-defined operations are going to allow a client like a web app to go through the process
of creating a front end for a task manager.
Now there are three words up above representational state transfer.
First up we have representation all with a REST API.
We are getting and working with representations of our data so the data is stored in the database but
using the REST API I can still fetch data I can manipulate data and I can perform all of those basic
CRUD operations.
So we're working with representations of our users and tasks.
Now when it comes to state transfer a REST API the server it's stateless.
The state has been transferred from the server to the client so each request from the client such as
a request from a web application contains everything needed for the server to actually process that
request.
This includes the operation they're trying to perform all of the data the operation actually needs in
order to work.
And it also includes things like authentication making sure that the user who's trying to perform the
operation is actually able to do so.
Now all of this will make way more sense once we actually put it into practice.
In practice the requests are gonna be made via HDTV requests so this is how a client like a web app
is going to be able to perform those predefined operations.
So right here we have a client and a server and the client is going to have a requirement like I need
task data to show on this page.
So it's going to make an H TTP request to a specific you are all on this server.
Here I am using the get h TTP method to make a request to forward slash tasks forward slash A E A where
this is the I.D. of the task I'm trying to fetch now in this case I'm short into the object I.D. for
this presentation as we've seen before.
Object ideas are a bit longer than just five characters so we make their request to the server the server
is going to be able to go through the process of fulfilling it it's going to find the data in the database.
In this case looking for the task by IED and it will send back as part of the TTP response.
So right here I have a status code in this case two hundred indicating that everything went well and
I have the Jason response with the data that was requested.
Now you most likely know about other status codes like 4 0 4 or 4 page not found.
And we'll explore the complete list of status codes available as we start to build out our API.
Now these server sends the data to the client and the client can actually render things with the rest
api though we'll be using more than just get requests to ask for data.
We're also going to be creating data deleting data and updating data.
So with that we still have a client and a server and we're still making an HDTV request after some need
needs to be fulfilled.
Something like Andrew and I need to create a to do so here.
I'm authenticating as myself and I'm trying to perform one of our predefined operations.
So right here I'm going to fire at the request off.
Now at this time we're no longer using the get HDTV method.
We're using a different method post which is used for creating data.
So here post forward slash tasks is going to allow us to create a new task.
And we're also sending along Jason with the request we're sending along things like the description
which we made required in the last video and the completed status which is optional.
Now when the server gets that it's going to authenticate making sure that we do indeed have an account.
Then it's going to create that to do associated with us.
And once the task has been created we'll get the response back.
Here we are seeing a different HDTV status code to a one which signifies that a resource was created.
And we're also getting a Jason response the new task that has been created.
The client will eventually get the response and it'll be able to use it to signify to the user in the
user interface that things went well and that the task was created.
Now we'll learn more about the various H TTP methods and status codes available to us in the next slide.
What I'd like to do is go ahead and talk about the predefined operations will typically have four our
resources and in this case we'll talk about some of the predefined operations we're gonna have for the
task resource in order for anyone to be able to do anything meaningful with our API.
We need to expose the necessary set of predefined operations for things like the CRUD operations create
read update and delete.
So let's start with C 4 create right here I have the following allowing you to create a new task now
every single REST API operation is defined with two pieces of data.
The TTP method and the path.
So in this case we are using the H TTP a post method to forward slash tasks and this is what we set
up for creating a resource.
Now imagine the resource changed.
Imagine I'm working with an e-commerce Web site and I want the ability to create a new product that
I'm selling for that I would use the post H TTP method with forward slash products where the thing that
comes after the forward slash is the poor realised version of the resource so tasks or products or orders
or anything else you might be working with after C for create.
We move on to our four read and when it comes to structuring your rest api you'll typically have to
read operations one to fetch multiple of a given resource and one to fetch a individual item like an
individual task.
Let's go ahead and start with the plural sized example.
So right here we have the operation for getting all of our tasks.
It is indeed a read operation and we're using a familiar H TTP method the get method.
So we have post for posting new data to the server and we have get for getting existing data.
Now you'll notice that the path is exactly the same forward slash tasks.
This is the setup we'll use when we're trying to get all of a given resource to bring us back to that
product's example.
It would be forward slash products to fetch all of the products.
Now there is that second Reid operation the ability to fetch an individual resource and for that we
have something like the following.
It's still a Reid operation and we're still using the TTP get method right here though you are L has
changed it's now forward slash tasks forward slash colon I.D. Now colon I.D. is a place holder this
will get replaced with some value and in the case of this particular path it'll get replaced with the
I.D. of the task we're trying to fetch so we're going to see forward slash tasks when we're working
with multiple of a resource and then forward slash tasks forward slash I.D..
When we're targeting an individual item.
So next up on our list of crud operations is you for update.
Right here we have that for update.
We use a third H TTP method patch which allows us to patch up our existing data.
In this case we could do something like make a task complete when it was previously incomplete.
Now in this case we're working with an individual task.
So we see these same you are all set up as we had up above.
It is only the TTP method that has changed and we'll learn how to actually manipulate these methods
as we start to build out the rest api.
Next up after update we have d for delete.
In this case we use the delete HDTV method followed by the same you are El structure we saw with the
last two because in the case of delete we are deleting an individual task by its I.D..
So these are the basic you are El structures we'll see.
We have forward slash resource where the resource name is Pla realized then we have forward slash plural
sized resource forward slash the idea when we're trying to manipulate an individual resource.
This is the common rest api structure and this is what we're going to work to build out in this section.
Now before we go there's one more thing I want to talk about as we put all of this into practice.
We're going to be sending hundreds of H TTP requests back and forth between the client and the server
and it's a good idea to know what exactly makes up an H TTP request.
What exactly is getting sent back and forth between the client and the server.
And the answer is that it's just some text.
So the structure of an H TTP request is text based.
Here I have an example request and there are three main pieces.
First up line number one this is known as the request line.
This contains the H TTP method being used the path and the TTP protocol.
In this case we know that the combination of post with forward slash tasks means that we're trying to
create a new task resource.
Now after that request line we have as many request headers as we need.
Here we have three except connection and authorization headers are nothing more than key value pairs
which allow you to attach meta information to their request.
So here we are using except to say that we're expecting Jason data back which is what we'll get.
We're using connection to say that we're likely to make other requests shortly.
So let's go ahead and keep this connection open to keep things fast.
And we're also setting authorization to setup authentication.
Now in this case I have trimmed that value as it's quite long but we'll learn how to set that up later.
Now we can have as many headers as we need in this case we have three.
After we're done with the headers we have an empty line followed by the request body.
So when we post data to forward slash tasks we have to provide that data and we provide it.
As Jason right inside of the request body down below I have the following where I set up description
giving it the value of order new drill bits.
Now you'll notice that I'm not providing a completed value because I can just fall back to the default
value which is false.
And that's exactly what I want now.
Once the server gets this request it's going to be able to pass it and express does great work for us
by giving us access to all of this in a much easier interface and it sends back a response which looks
quite similar to the request.
Here we have the status line which contains the protocol followed by the status code followed by a text
representation of the status code.
So in this case our protocols match up the status code is to a one and two a one stands for created
much like for 0 four stands for not found and once again you'll see a complete list of the status codes
available shortly.
Next up we have our response headers so down below.
I have three headers date server and content type date just signifies the time when all of this happened
the server would be expressed and the content type is metadata about what's below.
In this case we're saying that it's Jason.
Next up we do indeed have an empty line followed by the response body which in this case is the complete
task with the I.D. and completed values set up.
And right here we have the description we provide it.
So we'll send body Jason in the request when we're trying to pass things over to the server and we will
get body Jason in the response for almost everything we do.
So this is the basics of what makes up a request and a response.
Now let's go ahead and start to put all of this into practice.
As far as visualization videos go.
I know this one was a bit long but it's important to understand everything that makes up an H TTP request
as well as the basic structure for the H TTP rest api resources which is what we explored in that last
slide.
All right that's it for this one.
Let's jump into the next one.