Hey, guys.
In the last lesson, we learned some of the basic vocab that's involved in computers communicating to
each other across the internet using HTTP,
but in this lesson, we're going to learn a bit more about how to make those requests, and especially
using a tool called Postman.
So let's get started.
Now, we already know that the purpose of our HTTP is for client computers to communicate with our server-
side.
Now, as we explained previously, the Client-Side could be anything that a user uses to access our
website.
So that could be a desktop, laptop or mobile,
and our Server-Side consists of everything from the computer that is running the server code to the
application, which in our case has been our index.js and even including a database which we have not
yet dived into, but we will in future modules.
In order to communicate between the client-side and server-side, we're making these HTTP requests that
come from the client to the server.
Now in the last lesson you've seen that we can also return a response from the server,
so here is our request going from left to right and here is our response going from right to left or
server to client.
And we've already seen that we can send text, we can send HTML, but we can also send a response.
Now, what kind of response?
Well, they're usually coded responses you might have already heard and probably come across the very
famous "404 response".
Now, what does 404 even mean and why is it a number?
Is it a post code?
Is it a zip code?
Is it a phone number?
What does it mean?
It's not any of those things.
It's in fact a HTTP Standard Status Response Code.
The response codes in HTTP are normally grouped into five categories, and this is from MDN Docs,
and it tells you that the numbers between 100 and 199 are usually informational.
The 200 are usually telling you that something went successfully.
The 300 are usually a redirection of the website where the server is redirecting you to a different
location for the thing that you're requesting.
The 400, including that famous 404, comes from client error responses.
So it means that the client has requested or done something that is not right and the 500 are the server-
side error responses.
So the server-side computer or the server-side application has something wrong with it and is not working
as a result.
So you can see all of these in more detail by going to developer.mozilla.org/docs/Web/HTTP/Status
and
if you scroll down here, you'll actually see a detailed breakdown of each of the HTTP status codes.
Now, for our purposes, the most common one we're going to be sending and using is the 201, which
basically just means that everything went A-OK.
So it doesn't matter what the request was.
It could have been a GET request trying to get some sort of resource,
then 200 means that the resource has been fetched and transmitted in the message body back to the client,
or the request could be a PUT, or POST, or PATCH, or even DELETE,
and all of these basically, went successfully and that's why the server is sending back the code of 200.
As you scroll down, there'll be other codes as well, for example, the 201 Created, which is when
you send a POST or PUT request and instead of returning something in the message body, sending something
back to the client, if nothing is sent back and everything was just posted successfully, then you can
in fact see a 201 code with your POST requests from the server.
In addition, there are other ones that are really specific to the type of request that you make,
for example, we know that the 404 is when the server cannot find the requested resource, which usually
means that you've typed in a wrong URL.
So instead of typing in google.com, you've typed in googl.com, although I think they've actually
bought all of the related domains just to make sure that you get redirected when that happens.
Actually I'm going to try it out.
Yeah, exactly.
So that was actually a redirect, and I know it's a redirect because I typed in Google without the E, and
I got sent back to Google and we can actually log this in our Network tab of our Console making sure
that you've got Preserve log checked and that down here in the filter you've got All selected.
So let me just repeat that again.
I'm going to type in googl without the e.com, hit Enter and you can see a whole bunch of things happen,
but the first thing that happened was a 301.
So let's go back and check in the 300.
What does a 301
mean?
It means that, "The URL of the requested resource has been changed permanently. The new URL is given
in the response," and you are redirected to the new location, which is kind of cool,
actually.
This is HTTP Status Codes in real life, but as I was saying if you're finding it difficult to remember
what each of the category of status codes means, there is this slide from Sander Hoogendoorn who gave
this keynote, and I kind of tend to think of HTTP Status Codes as his categories.
So in the 100's, it means, hold on, something's happening or I'm giving you some information.
In the 200's, it's success.
Here you go.
Here's what you wanted.
Here, have it.
300's is go away, which is in our case, redirect.
So we went to googl.com and it said go away and go instead to here, which is the URL that it returned
to us and also redirected there.
The 400 means that you have screwed up, you as in the client-side, the person making the request and
the 500 means that I have screwed up, which means that I as in the server side, there is some sort
of resource that's missing or there's a bug in my code on the server application.
These are all valid 500 responses.
I find this a lot easier to remember than the official one, but it's also worth checking the MDN Docs when
you get a specific code and you need to look up what it means.
Now,
previously we learned about these HTTP request methods and we learned about how to use the GET request
to start fetching things from our server to handle multiple endpoints, to send back different types
of things such as text or HTML,
but now I want to dive into some of the other requests that we can make, such as POST, PUT, PATCH
and DELETE.
A POST request is usually made from some form of HTML form, and this includes things such as, for example,
a sign-up page where you need to put in your name, your username, email address, etcetera.
And that request goes to our server via a POST request so that data is sent along with that request
and hopefully the server will do something with that request, maybe putting it into a database, maybe
validating it, maybe doing whatever it may be, and then once it's done, it'll send back either a
200 with some piece of information or a 201 response where there's no information being passed back
and actually, everything was just successfully posted.
If we don't want to create the front-end for the POST, PUT PATCH and DELETE response, which very often
when you're creating APIs, when you're creating back-ends, you don't actually have the time to do,
you just want to write the code first and get it tested so that the front-end team can do all the rest
of the stuff.
What do you do in that case?
Well, there's a really great tool that professional developers love to use, which is called Postman.
Postman can be downloaded for free at postman.com/downloads.
And once you've downloaded it and have it running, it looks something like this.
You can target a specific URL or an endpoint and you can also specify the type of request you want to
make.
For example, I've got several tabs here open with different requests that I'm testing.
This is a POST, this is a GET, this is a PUT and you can see in the dropdown when you make these
requests, you can specify which if any of the different types of methods you want to use,
and then you can add in your URL, add in your endpoints, etcetera.
And then you can also add values to the body.
So for example, if I want to create a new POST request to my local host, I can change this to POST
and I can go into the body and add in some URL encoded form-data.
So I could say, well, in this field, the key is called name and the value that I've entered is my name.
I've also got another field called email, in which case I want the testing data to be this,
etcetera, and so on and so forth.
So without needing to do any of the front-end hard work, we can already start testing by sending these
requests to a particular location.
Now we're getting an error, connection
refused because I don't have a port open on 3000.
I don't have my localhost up and running with my server and I don't yet have any of the code written.
The code is pretty straightforward as we saw previously, there are different methods for each of the
HTTP requests that comes from Express.
They've vastly simplified this code compared to using just straight up Node, and this is why most Node
developers will use Express along with Node.
So previously we saw how to write the GET method.
We add in the endpoint, we have our anonymous function, including a request and response parameter,
and then we can send back in the response, whatever it is we want,
in response to this particular request.
The POST request is simply using the post method. The PUT, the PATCH, the DELETE, all work very, very
similarly, and we can use the res.sendStatus to actually send back a status code instead of a piece
of text or HTML as well.
Now, when we run this particular website and get the server up and running, the only one that's really
going to work in the browser is our app.get and it's going to send back this HTML of the Home Page.
The rest of them are, in our case, not sending back anything other than a status code.
So it's best that we actually test this inside Postman and because we're testing everything inside
Postman, we don't even need to send the client-side anything other than a status code.
Let's go ahead and try an exercise and I want you to download the zipped file 3.3 Postman from this current
lesson.
And once you've extracted all the files, you'll see I've included all of the different HTTP methods
that we spoke about just now, and this is mimicking a website where we have a registration route where
we can POST data from an HTML form and then we're going to do something fancy in here like save the data
or do something with it,
but basically, we're simply just going to send back a success response in this case because I want to
show you how to use Postman and hit up all of these different routes on our server.
Now, one thing to remember whenever you download Node projects from the Internet is usually they will
not come packaged with the actual node_modules because there's a lot of dependencies, and there's dependencies
on dependencies.
So it can get very, very large basically.
So people normally don't ship that,
and instead what you want to do is you want to cd over to the project that you downloaded, such as
in your case, and then you simply run, "npm install" without any names of any NPM packages and this command
will simply go through the package.json,
look at all the dependencies that are listed, in which case there is only one currently, express, but
in most projects there will be several and then it will go through and do the
necessary installations and add your node modules folder.
Once you've done that, we can go ahead and use Nodemon to start our server.
And I want you to open up Postman and go ahead and test out each of the routes.
Take a look at what the endpoints are and make sure that you get the relevant and correct status code
sent back to, you know, 404's or 500's or any of that and see if you can create a Tab for each of the
five requests here.
GET, POST, PUT, PATCH and DELETE.
Make sure you hit up the right endpoints and send those requests to get back a successful response status
code.
So pause the video now and complete this challenge.
All right, so we need a five tabs.
Let's start with the first one.
We want to make a GET request to our localhost:
3000.
Now, if we check our endpoint, you can see the get is to the root route.
So we can either add that forward slash or we can leave it out.
It doesn't really matter.
It goes to the same place anyways.
Now we can go ahead and click Send, to send this request and hopefully, if our server is up and running
as it is here, then we get back our h1, which is what we wanted to send back,
and also we can see the status code is 200, which means that everything went A-OK.
Let's go ahead and do the next one.
So this is going to be a POST request also to localhost:3000.
And this time, though, we have a different endpoint.
We want to hit up the register endpoint because you can imagine if you have a complex website and you
need to do multiple POST and GET or PUT requests, you want to make sure that you're routing those requests
to the right endpoints.
So if we wanted to sign up a new user, then we might need to have some form data.
Now, we're not really too bothered about this at the moment because I'm not actually handling it on the
server side at all,
I just wanted to make sure that you knew how to send a POST request to the right address.
So we've actually got all of the required parts and if I just hit Send, it should come back with 201
Created and if you hover over it, it tells you the meaning of that code, which is, "The request has
been fulfilled and resulted in a new resource being created."
Perfect.
The next one is a PUT request to this particular endpoint.
Now we can choose our PUT request and then add our localhost:3000/user/angela.
The
situation that we are mimicking in this case is let's say you have a particular user and they have
a username,
if you wanted to update some piece of information for this user, say their email address or their password,
then you're probably going to use a PUT request to be able to tell the server which user you want to
change.
I'm not going to add anything more to the body.
In reality, it might be like the new email that I want to update it to, instead of angela@gmail.com,
maybe I want to change the email.
Now let's hit Send and we get back status 200, which means everything went okay. Because this is a PUT request
which means we're replacing everything about a particular resource,
then normally you are actually going to send all of the entire data.
So you would maybe GET all of the data for your user.
So their email, their first name, their last name, their address, whatever it is that you've stored
on your database for that particular user, you would fetch it first and then you would send back all
of the new values and completely replace that resource.
However, a PATCH request which we've also got here in our server works a little bit differently where
again hitting up localhost:3000, patching this user with the username of Angela.
In this case we can actually simply just change one thing.
So maybe we want to change their first name instead of Angela,
I'm going to call myself Angla, whatever it may be.
And now when we hit Send, you can see our PATCH route is also working.
Finally is our DELETE request, which is the easiest of all.
It doesn't require anything to be sent other than making sure we hit up the right path, which in this
case is probably a path that's going to DELETE that user with that particular username.
So we'll do some code magic on our back-end,
and then hopefully once this is sent, we get back the status 200, which means that it was successful
and we managed to successfully delete that user.
So of course all of that server code for deleting user or updating user, or whatever has to be written.
Now in this case, we're simply just sending back the status code, but in reality it would be a case
of deleting the user.
If everything went successfully, we would send back 200.
If there was some other sort of issue, we might send back a different status code.
But this is a really good point to introduce you to HTTP Status Codes as the response and also the different
HTTP methods,
and hopefully, you've seen how you can test those super easily and quickly using Postman.
That's all for this lesson.
In the next lesson, we're going to learn more about Express Middleware and we're going to see how we
can actually tap into these values that we're sending over in our requests and how we can get hold of
it on our back-end.
So for all of that and more, I'll see you in the next lesson.