Hey, guys. 1
In the last lesson, we learned some of the basic vocab that's involved in computers communicating to 2
each other across the internet using HTTP, 3
but in this lesson, we're going to learn a bit more about how to make those requests, and especially 4
using a tool called Postman. 5
So let's get started. 6
Now, we already know that the purpose of our HTTP is for client computers to communicate with our server- 7
side. 8
Now, as we explained previously, the Client-Side could be anything that a user uses to access our 9
website. 10
So that could be a desktop, laptop or mobile. 11
And our Server-Side consists of everything from the computer that is running the server code to the 12
application, which in our case has been our index.js and even including a database which we have not 13
yet dived into, but we will in future modules. 14
In order to communicate between the client-side and server-side, we're making these HTTP requests that 15
come from the client to the server. 16
Now in the last lesson you've seen that we can also return a response from the server, 17
so here is our request going from left to right and here is our response going from right to left or 18
server to client. 19
And we've already seen that we can send text, we can send HTML, but we can also send a response. 20
Now, what kind of response? 21
Well, they're usually coded responses you might have already heard and probably come across the very 22
famous "404 response". 23
Now, what does 404 even mean and why is it a number? 24
Is it a post code? 25
Is it a zip code? 26
Is it a phone number? 27
What does it mean? 28
It's not any of those things. 29
It's in fact a HTTP Standard Status Response Code. 30
The response codes in HTTP are normally grouped into five categories, and this is from MDN Docs, 31
and it tells you that the numbers between 100 and 199 are usually informational. 32
The 200 are usually telling you that something went successfully. 33
The 300 are usually a redirection of the website where the server is redirecting you to a different 34
location for the thing that you're requesting. 35
The 400, including that famous 404, comes from client error responses. 36
So it means that the client has requested or done something that is not right and the 500 are the server- 37
side error responses. 38
So the server-side computer or the server-side application has something wrong with it and is not working 39
as a result. 40
So you can see all of these in more detail by going to developer.mozilla.org/docs/Web/HTTP/Status 41
and 42
if you scroll down here, you'll actually see a detailed breakdown of each of the HTTP status codes. 43
Now, for our purposes, the most common one we're going to be sending and using is the 201, which 44
basically just means that everything went okay. 45
So it doesn't matter what the request was. 46
It could have been a GET request trying to get some sort of resource, 47
then 200 means that the resource has been fetched and transmitted in the message body back to the client, 48
or the request could be a PUT, or POST, or PATCH, or even DELETE, 49
and all of these basically, went successfully and that's why the server is sending back the code of 200. 50
As you scroll down, there'll be other codes as well, for example, the 201 Created, which is when 51
you send a POST or PUT request and instead of returning something in the message body, sending something 52
back to the client, if nothing is sent back and everything was just posted successfully, then you can 53
in fact see a 201 code with your POST requests from the server. 54
In addition, there are other ones that are really specific to the type of request that you make, 55
for example, we know that the 404 is when the server cannot find the requested resource, which usually 56
means that you've typed in a wrong URL. 57
So instead of typing in google.com, you've typed in googl.com, although I think they've actually 58
bought all of the related domains just to make sure that you get redirected when that happens. 59
Actually I'm going to try it out. 60
Yeah, exactly. 61
So that was actually a redirect and no, it's a redirect because I typed in Google without the E, and 62
I got sent back to Google and we can actually log this in our Network tab of our Console making sure 63
that you've got Preserve log checked and that down here in the filter you've got All selected. 64
So let me just repeat that again. 65
I'm going to type in googl without the e.com, hit Enter and you can see a whole bunch of things happen, 66
but the first thing that happened was a 301. 67
So let's go back and check in the 300. 68
What does a 301 69
mean? 70
It means that, "The URL of the requested resource has been changed permanently. The new URL is given 71
in the response," and you are redirected to the new location, which is kind of cool, 72
actually. 73
This is HTTP Status Codes in real life, but as I was saying if you're finding it difficult to remember 74
what each of the category of status codes means, there is this slide from Sander Hoogendoorn who gave 75
this keynote, and I kind of tend to think of HTTP Status Codes as his categories. 76
So in the 100's, it means, hold on, something's happening or I'm giving you some information. 77
In the 200's, it's success. 78
Here you go. 79
Here's what you wanted. 80
Here, have it. 81
300's is go away, which is in our case, redirect. 82
So we went to googl.com and it said go away and go instead to here, which is the URL that it returned 83
to us and also redirected there. 84
The 400 means that you have screwed up, you as in the client-side, the person making the request and 85
the 500 means that I have screwed up, which means that I as in the server side, there is some sort 86
of resource that's missing or there's a bug in my code on the server application. 87
These are all valid 500 responses. 88
I find this a lot easier to remember than the official one, but it's also worth checking the MDN Docs when 89
you get a specific code and you need to look up what it means. 90
Now, 91
previously we learned about these HTTP request methods and we learned about how to use the GET request 92
to start fetching things from our server to handle multiple endpoints, to send back different types 93
of things such as text or HTML, 94
but now I want to dive into some of the other requests that we can make, such as POST, PUT, PATCH 95
and DELETE. 96
A POST request is usually made from some form of HTML form, and this includes things such as, for example, 97
a sign-up page where you need to put in your name, your username, email address, etcetera. 98
And that request goes to our server via a POST request so that data is sent along with that request 99
and hopefully the server will do something with that request, maybe putting it into a database, maybe 100
validating it, maybe doing whatever it may be, and then once it's done, it'll send back either a 101
200 with some piece of information or a 201 response where there's no information being passed back 102
and actually, everything was just successfully posted. 103
If we don't want to create the front-end for the POST, PUT PATCH and DELETE response, which very often 104
when you're creating APIs, when you're creating back-ends, you don't actually have the time to do, 105
you just want to write the code first and get it tested so that the front-end team can do all the rest 106
of the stuff. 107
What do you do in that case? 108
Well, there's a really great tool that professional developers love to use, which is called Postman. 109
Postman can be downloaded for free at postman.com/downloads. 110
And once you've downloaded it and have it running, it looks something like this. 111
You can target a specific URL or an endpoint and you can also specify the type of request you want to 112
make. 113
For example, I've got several tabs here open with different requests that I'm testing. 114
This is a POST, this is a GET, this is a PUT and you can see in the dropdown when you make these 115
requests, you can specify which if any of the different types of methods you want to use, 116
and then you can add in your URL, add in your endpoints, etcetera. 117
And then you can also add values to the body. 118
So for example, if I want to create a new POST request to my local host, I can change this to POST 119
and I can go into the body and add in some URL encoded form-data. 120
So I could say, well, in this field, the key is called name and the value that I've entered is my name. 121
I've also got another field called email, in which case I want the testing data to be this, 122
etcetera, and so on and so forth. 123
So without needing to do any of the front-end hard work, we can already start testing by sending these 124
requests to a particular location. 125
Now we're getting an error connection 126
refused because I don't have a port open on 3000. 127
I don't have my localhost up and running with my server and I don't yet have any of the code written. 128
The code is pretty straightforward as we saw previously, there are different methods for each of the 129
HTTP requests that comes from Express. 130
They've vastly simplified this code compared to using just straight up Node, and this is why most Node 131
developers will use Express along with Node. 132
So previously we saw how to write the GET method. 133
We add in the endpoint, we have our anonymous function, including a request and response parameter, 134
and then we can send back in the response whatever it is we want 135
in response to this particular request. 136
The POST request is simply using the post method. The PUT, the PATCH, the DELETE, all work very, very 137
similarly and we can use the res.sendStatus to actually send back a status code instead of a piece 138
of text or HTML as well. 139
Now when we run this particular website and get the server up and running, the only one that's really 140
going to work in the browser is our app.get and it's going to send back this HTML of the Home Page. 141
The rest of them are, in our case, not sending back anything other than a status code. 142
So it's best that we actually test this inside Postman and because we're testing everything inside 143
Postman, we don't even need to send the client-side anything other than a status code. 144
Let's go ahead and try an exercise and I want you to download the zipped file 3.3 Postman from this current 145
lesson. 146
And once you've extracted all the files, you'll see I've included all of the different HTTP methods 147
that we spoke about just now, and this is mimicking a website where we have a registration route where 148
we can POST data from an HTML form and then we're going to do something fancy in here like save the data 149
or do something with it, 150
but basically, we're simply just going to send back a success response in this case because I want to 151
show you how to use Postman and hit up all of these different routes on our server. 152
Now, one thing to remember whenever you download Node projects from the Internet is usually they will 153
not come packaged with the actual node_modules because there's a lot of dependencies and the dependencies 154
on dependencies. 155
So it can get very, very large basically. 156
So people normally don't ship that, 157
and instead what you want to do is you want to cd over to the project that you downloaded, such as 158
in your case, and then you simply run, "npm install" without any names of any NPM packages and this command 159
will simply go through the package.json, 160
look at all the dependencies that are listed, in which case there is only one currently, express, but 161
in most projects there will be several and then it will go through and do the 162
necessary installations and add your node modules folder. 163
Once you've done that, we can go ahead and use Nodemon to start our server. 164
And I want you to open up Postman and go ahead and test out each of the routes. 165
Take a look at what the endpoints are and make sure that you get the relevant and correct status code 166
sent back to, you know, 404 or 500 or any of that and see if you can create a Tab for each of the 167
five requests here. 168
GET, POST, PUT, PATCH and DELETE. 169
Make sure you hit up the right endpoints and send those requests to get back a successful response status 170
code. 171
So pause the video now and complete this challenge. 172
All right, so we need a five tabs. 173
Let's start with the first one. 174
We want to make a GET request to our localhost: 175
3000. 176
Now, if we check our endpoint, you can see the get is to the root route. 177
So we can either add that forward slash or we can leave it out. 178
It doesn't really matter. 179
It goes to the same place anyways. 180
Now we can go ahead and click Send to send this request and hopefully, if our server is up and running 181
as it is here, then we get back our h1, which is what we wanted to send back, 182
and also we can see the status code is 200, which means that everything went okay. 183
Let's go ahead and do the next one. 184
So this is going to be a POST request also to localhost:3000. 185
And this time, though, we have a different endpoint. 186
We want to hit up the register endpoint because you can imagine if you have a complex website and you 187
need to do multiple POST and GET or PUT requests, you want to make sure that you're routing those requests 188
to the right endpoints. 189
So if we wanted to sign up a new user, then we might need to have some form data. 190
Now we're not really too bothered about this at the moment because I'm not actually handling it on the 191
server side at all, 192
I just wanted to make sure that you knew how to send a post request to the right address. 193
So we've actually got all of the required parts and if I just hit Send, it should come back with 201 194
Created and if you hover over it, it tells you the meaning of that code, which is, "The request has 195
been fulfilled and resulted in a new resource being created." 196
Perfect. 197
The next one is a PUT request to this particular endpoint. 198
Now we can choose our PUT request and then add our localhost:3000/user/angela. 199
The 200
situation that we are mimicking in this case is let's say you have a particular user and they have 201
a username, 202
if you wanted to update some piece of information for this user, say their email address or their password, 203
then you're probably going to use a PUT request to be able to tell the server which user you want to 204
change. 205
I'm not going to add anything more to the body. 206
In reality, it might be like the new email that I want to update it to instead of angela@gmail.com, 207
maybe I want to change the email. 208
Now let's hit Send and we get back status 200, which means everything went okay. Because this is a PUT request 209
which means we're replacing everything about a particular resource, 210
then normally you are actually going to send all of the entire data. 211
So you would maybe GET all of the data for your user. 212
So their email, their first name, their last name, their address, whatever it is that you've stored 213
on your database for that particular user, you would fetch it first and then you would send back all 214
of the new values and completely replace that resource. 215
However, a PATCH request which we've also got here in our server works a little bit differently where 216
again hitting up localhost:3000, patching this user with the username of Angela. 217
In this case we can actually simply just change one thing. 218
So maybe we want to change their first name instead of Angela, 219
I'm going to call myself Angla, whatever it may be. 220
And now when we hit Send, you can see our PATCH route is also working. 221
Finally is our DELETE request, which is the easiest of all. 222
It doesn't require anything to be sent other than making sure we hit up the right path, which in this 223
case is probably a path that's going to DELETE that user with that particular username. 224
So we'll do some code magic on our back-end, 225
And then hopefully once this is sent, we get back the status 200, which means that it was successful 226
and we managed to successfully delete that user. 227
So of course all of that server code for deleting user or updating user, or whatever has to be written. 228
Now in this case, we're simply just sending back the status code, but in reality it would be a case 229
of deleting the user. 230
If everything went successfully, we would send back 200. 231
If there was some other sort of issue, we might send back a different status code. 232
But this is a really good point to introduce you to HTTP Status Codes as the response and also the different 233
HTTP methods, 234
and hopefully, you've seen how you can test those super easily and quickly using Postman. 235
That's all for this lesson. 236
In the next lesson, we're going to learn more about Express Middleware and we're going to see how we 237
can actually tap into these values that we're sending over in our requests and how we can get hold of 238
it on our back-end. 239
So for all of that and more, I'll see you in the next lesson.