This video is sponsored by DevMountain. If you're interested in learning web development, iOS, or UX design, DevMountain is a 12-week design and development bootcamp intended to get you a full-time position in the industry. To learn more visit devmountain.com or click the link in the description below. Hey, what's going on guys?
So in this video I want to talk about something that I think isn't talked about often enough and that's the HTTP protocol that we as web developers work with every day and Whether you're a back-end full stack or even front-end developer It's important to understand HTTP and the whole request response cycle. So in this video, we're going to touch on how all this works We'll look at the different types of responses methods status codes and you know what you get back from a server when you send a request and we're going to go through some slides and i'd like to test some of this stuff out with node.js and express along with postman which is an http client and i think express is a great framework to kind of give you some examples of how http works because we handle everything ourselves it's very minimalistic We handle the request, the response directly, rather than having it be abstracted like it is in many higher level frameworks. So even if you're not familiar with Express or Node, that's fine. We're not focusing on the specific framework or language. So let's first talk about what HTTP is.
It stands for Hypertext Transfer Protocol, and it's basically responsible for communication between web servers and clients. It's the protocol of the web. So every time you open up your browser and you visit a web page or you submit a form or you click a button that sends some kind of Ajax request or fetch request, something like that, you're using HTTP and you're going through what's called the request and response cycle. You make a request and you get a response back that has something called headers and something called the body. And we're going to look more into that cycle in a bit.
All right, so it's important to understand that HTTP is stateless, meaning that every request is completely independent. When you make one request visiting a web page, or you go to another page after that, or reload the page, it doesn't remember anything about the previous transaction. You can kind of look at each request as a single transaction.
Now there's other things we can utilize to, for instance, hold login data. and make a more enhanced user experience, things like programming, local storage, cookies, sessions, stuff like that. But just know that HTTP at its core is completely stateless. So what is HTTPS? And I'm sure that a lot of you guys know this stuff, but just for people that don't, HTTPS stands for Hypertext Transfer Protocol Secure, and it's basically where all the data that's sent back and forth is encrypted by something called ssl which stands for secure sockets layer or by tls which is the transport security layer so anytime you have users that are sending sensitive information you should always it should always be over https especially if it's like credit card data social security numbers you want to have a high level of security for that stuff and even things like contact forms you should have https A lot of websites and applications now are just forcing HTTPS on every page, which isn't a bad idea.
And you can do this by installing an SSL certificate on your web host. And there's different levels of security, different levels of certificates as well. All right, so when a request is made to a server, it has some kind of method attached to it. And there's more than this.
These are the main four that you're going to be working with. And these are the ones I'm going to go over, but just know there are a couple more. So a get request is used when you want to get or fetch data from the server.
This could be just loading a standard HTML page, loading assets like CSS or images, JSON data, XML data, and so on. So every time you visit a web page, you're making a get request to the server via HTTP. Now a post request is usually used when you're posting data, when you're adding something to the server, adding a resource. Typically when you submit a form like let's say a contact form, you'll be making a post request.
If you're submitting maybe a blog post, you're creating a new blog post, that's going to be a post request. You're sending data to the server and typically that data will be stored in a database somewhere. You can also have forms that make get requests but it's less secure because The stuff that you send in the form is actually going to be visible in the URL. So typically you don't want to use a get request with a form unless it's some kind of search form where all you're doing is filtering data that's coming back from the server.
You're not actually posting anything. All right. And then we have put requests, which is used to update data that's already on.
on the server. So if you have a blog post, you want to edit it, maybe change the image or change some text, typically you would do that with a put request. And then a delete request, of course, just deletes data from the server. All right, so with each request and response using HTTP, you have something called a header, you have something called a body.
So the body typically with a response is going to be the HTML page that you're trying to load, the JSON data, whatever is being sent from the server. And then when you make a request, you can also send a request body. For instance, when you submit a form, the form fields you're submitting are part of the request body. Now when it comes to the header, you also have request headers and response headers in something called a general header. So it's basically divided into three parts, and there's different fields on each part.
So typically a header will look something like this. You'll make a method like a get request to a path. or URL with a protocol, in this case, HTTP 1.1.
And then you'll have all these different header fields. And a lot of these, you're not really going to need to care about, but it's good to know what some of the more common ones do and what they are, especially with the general part of it. So in general, we have the request URL, which is pretty straightforward. It's just the URL you're requesting the request method. So if it's a get request, post request, and so on.
The status code, this is probably the most important, and I'm going to go over status codes in the next slide. The remote address, which is the IP of the remote computer, the refer policy. So if you're if you go to a page from another page, it might have some information on that and whatever the Paul refer policy is. I'm not that familiar with it. The response header fields, you have server.
So if it's Apache or NGINX or something like that. And a lot of times this will be hidden just to prevent hackers from knowing what type of server the website uses. So setCookie is used for servers to send small pieces of data called cookies from the server to the client.
And then content type. So every response has a content type. For instance, if it's an HTML page, it'll have a content type of text slash HTML.
CSS files would be text slash CSS. Images, you have image slash PNG, image slash JPEG. If it's JSON data, it'll be application slash JSON. This is something that I think is really important to know, the different content types. And then you also have the content length, which is just that.
It's the length. It's in octets, which are, I believe, 8-bit bytes. And then also the date.
And there's other fields as well, but I'm not going to list every single one or every possible one. So some common request fields are cookies now if you have a cookie that was previously sent by the server and you need to send it back to the server you would do it in this field you also have a bunch of accept fields like accept encoding accept character set accept language these are just the the different encodings and languages and stuff that the client is able to understand okay content type again so if you're sending data Like let's say you're sending JSON, you'd want to set this to application slash JSON. And then you also have content length as well.
So authorization, remember HTTP is stateless, so you might need to send some type of token within the header, the authorization in the header, so that you can, for instance, validate a user to access a protected route or a protected page, unless you're using something like sessions on the server. And then the user agent is typically a long string that has to do with the software that the user is is using. So the operating system, the browser, things like that. And then the refer has info regarding the referring site if you were to click on a link or whatever. So these are just some of the more common header fields.
But there are more. So if you want to check out the HTTP spec, you can look more into that. All right, so HTTP status codes are really important to understand, at least the most common ones. So basically you have ranges.
You have the 100 through 500 range. So 100 is informational. Basically this means the request has been received and the process is continuing, it's processing.
200 means that it was successful, so successfully received, understood, and accepted. The 300 range usually has to do with... redirection or further action must be taken. 400 range is a client error, meaning that the request doesn't have what it needs from the client.
So let's say the server needs a name field sent in the request body and you don't send that. You're going to get a 400 error or somewhere in that range. And then 500 is usually a server error. So the server failed to fulfill an apparent valid request.
So everything seems okay as far as what you send to the server, but you still get an error. Something's wrong on the server side. Now, these are some important status codes, or I should say common status codes, that you should remember. So 200 is just okay. It means everything is fine.
You make the request. You get the HTML page, you get a 200 response. 201 is okay, but it means something was created.
So if you're creating a blog post and everything goes okay, then you might get a 201 response. 301 is usually moved to a new URL, so this has to do with redirection. 304 is typically not modified, meaning that if you visit a page and it gets cached and it hasn't changed at all, then you'll have a 304. Response or status 400 again bad requests.
So if you're not sending the correct data to the server 401 is typically or is unauthorized. So if you are missing a token or something like that you're not authorized you might get a 401 404. We all know what that means. It's not found. If you're looking for some page on the server that doesn't exist or some resource that doesn't exist you're going to get a 404. and then 500 is just an internal server error this could mean pretty much anything on the server side all right so those are the status codes those are really important to really memorize and understand so the last thing i want to quickly mention is that there is http version 2. we've been dealing with 1.1 for a long long time now all the changes to version 2 are pretty much under the hood meaning you don't have to go and change the way your applications work all the status codes everything like that is all the same it's just faster and more efficient okay so it does stuff like reduces latency by enabling full request and response multiplexing so it's faster it's more efficient it's more secure and this is a just a simple image to kind of show you that it can you can use multiplexing so for instance we get our html page get a response get our style sheet get our response, get our script, get our response.
So this is 1.1 with HDB to multiplexing. We can get our HTML and then get all of our scripts and style sheets basically in one shot here and send the responses at the same time. Now I'm not extremely familiar with HDB to I haven't read the spec.
I haven't worked with it that much, but just know it is available. It is out there. So you might want to look more into it.
All right, so now we're going to jump into Express so I can give you some examples on dealing with request body and headers and sending status codes and stuff like that. All right, guys, so we're going to jump into our little Express server in a second, but I just want to first show you an example on an actual website. I'm just going to use my Twitter profile, but you can go to any website you want and go to your dev tools, in my case, my Chrome dev tools, and then click on the network tab.
And if I go ahead and reload the page here, it's going to make all the requests it needs. It's going to get all the files from the server and it's going to show them down here. So you can see the different types, the status of 200, which means they everything's OK. The size.
This is the document, the main HTML document. And then we have all of our JavaScript files, our style sheets, our images, XHR, which is any Ajax requests that were made. But let's take a look at the main document here.
And under response, you're going to see the body, which is, of course, the HTML file. OK, same thing with preview. Now, headers is where you can actually see all the different header fields.
And remember, in the slides, I showed you that there's three different sections general response and request. So if we look at general, you can see our request URL, which is just the entire URL. The request method is get we made to get requests. Status code is 200, so everything's okay.
We get a little green dot, the remote address, and refer policy. Now, if we look in response, we have things like cache control. There's a bunch of stuff here that I'm not going to explain.
Some of this stuff I don't even understand. But we have the content length, their security policy, and then down here we should have the content type, which is text HTML. The character set is UTF-8. The date, what else? here we have set cookie so they set some cookies on the client status 200 down here we have like response time stuff like that and then in the request headers we have the authority which is the the root domain we have it's a get request the path is my profile HTTP s is the Scheme and then down here at the very bottom we have the user agent which is this long string which describes my environment So it has tells you I'm on a Mac Intel based OS X It's kind of confusing because it says Mozilla.
It says Safari and Chrome. I'm actually on Chrome So it shows the version of Chrome that I'm on. Alright, so that's the user agent So I just want you to take note of these values after what we went through in the slides And if you want to narrow it down by files, we can see like all the CSS that was loaded.
So if I click on one of these, I can see all the info for that file, including the content type, which is text CSS. If I want to look at the Ajax request here, so like this one right here, this should be application slash Jason. And if we look at the response, this is what it got us.
So the number of results, I guess some user information. So these are all the different XHR or Ajax requests that were made. All right. So when you use the fetch API or Axios or old school Ajax, this is where it's going to show up.
So just get familiar with the network tab. It's it's it can be a little daunting at first, but it's it's really helpful. It lets you know what's going on.
It shows you the load times and all that stuff. All right. So enough with that. Let's jump into I'm going to show you postman first.
And if you don't have this. Clients, which is just awesome, especially if you're building api's you can get it at get postman calm And as you can see I can make any type of request So get post put patch delete all these other ones to any url in fact. I'll go ahead and make a request to Twitter.com slash Traverse you media Slash okay, and I'm going to make sure it's a get request just like the browser made and I'm going to get the same exact thing.
I'm going to get all the HTML. It doesn't render it. Well, actually, can we preview it?
I've never actually tried to preview HTML is disabled. Would you like to proceed legacy? Yeah.
So whatever you get the HTML and then headers will give you all the response headers so we can see the content type that we're getting set cookie status, all that stuff. If we want to look at the cookies, we have that tab as well. It shows us the status up here as well with the load time and the size.
OK, so we can make any requests from here that we can make in the browser and more because we can actually do put and delete and all that stuff. So this is a fantastic tool for testing APIs that you're building. So let's jump into express real quick.
I just have a basic express server running here on localhost 5000 and. Don't worry about it if you're not familiar with Express. Basically, all we're doing here is bringing it in, initializing it, setting it to listen on port 5000, and we have one endpoint, meaning that if we make a get request, so we said app.get to slash, which is the index page, it's going to run this function that has access to this request and response object. And with our response object, we can call.send, which will just send basically just...
whatever we put in here to the client. Okay. In this case, just a string of hello from express.
So if I go to postman and I make a get request to HGDP local host port 5,000, I get hello from express and I could do the same thing in the browser, get hello from express. All right. And if I open my Network tab and reload up. I'm gonna go to all here and you can see that I get a 304 Which means not modified because it was cached and it didn't change so it gave me this 304 if I were to Change this like say hello from Express one and save and go and reload now I get a 200 if I reload again. I get a 304 because it didn't change but over here.
I can see all my headers So same stuff that I saw with Twitter, there's just a lot less because there's a lot less going on. All right, so in Postman, same thing, I can see all my headers. Now with Postman, I can send all kinds of stuff.
I can send a request body, I can send headers. So we have a lot more freedom to basically interact with the request and response cycle. Now in Express, actually one thing I wanted to show you is the content type.
which by default, if you use res.send and you just send a string, it's going to be HTML. Okay, in fact, I could. Put I don't want to make this too much about express, but I could put HTML right in here. And if I go to my browser, you can see that that actually renders. All right.
Now, if I were to put Jason in here, let's get rid of this and let's say MSG, we'll just say message. Hello. And I save that and we go back to postman and send. You can see the content type has changed.
So with express res.send will basically detect the content type as best as it can okay but there is a res.json which is what you should use if you're sending json so if i do that it'll give me the same thing all right it shows the json in the body now we can also get our header values or header fields if we want so i'm just going to do a a res.send just to kind of show you the output of this. But if I take my request object, I can do.header and then in parentheses any header value I want, like let's say the host. So I save that and I go back to Postman and send.
I get a response with my host, localhost 5000. Okay, if I wanted, let's say the user agent, we'll do user-agent. And if we go back and send, we get In this case, Postman runtime because I'm using Postman as a client. So this is going to be different than what we saw in Chrome.
If I go back to Chrome and reload, we're going to see this, okay, which is different because we're using a different utility, a different client. All right. So just wanted to show you we could do that.
We can also get just the raw headers. So basically all of them, if we do request dot raw headers, And if we go back to postman and send, you can see we basically get an array with all the headers, the cash control postman token, since we're using postman, the user agent, the accept value, the host, all that stuff. OK, and we can send headers as well, which I'll show you in a little bit so we can get header values.
What else do I want to show you? So let's actually. Let's change this to a different row.
Let's do like slash contact. We'll say that this is a contact form. And what I want to show you now is how we can send data to the server in the request body. When we send a request, we can attach data to that, to the body.
And the way that we access that, I'll just go ahead and send it so we can view it. The way that we access that is with that request object has body. So request dot body.
Now, this won't work. for for adjacent data unless you put this piece of middleware in and it won't work for form data unless you put this in. That's just an express thing. All right. But let's go ahead and save that.
Excuse me. And let's make a request here to actually I want to I'm sorry, I want to change it to a post request. OK, if you're sending data, you want it to be a post.
So we simply change get to post here. So I'm going to save that and go back. And then make a post request to slash contact. Now, if I just send it as is, I get an empty object because request.body is empty.
However, if I want to send any data, I can click on the body tab. And typically, you would do this in your front end, like in your JavaScript, whether it's React or Angular or whatever. But this is just for basically testing APIs.
So from here, I could send form data if I want. Now notice when I click this www form URL encoded, it automatically puts a content type in my header. Okay, because you need to send this along too.
So we're actually sending a header value here. And then in the body, I could put a key like let's say name. So this is just simulating a form on a website. So we'll say value Brad.
And let's do email and Brad at Gmail. Okay, so if I go ahead and send that, we're going to see that down here because we sent that, we sent the request.body. If I do just request.body.name and I send that, we just get Brad.
All right. And you see how I sent the content type in the header. If I want to access that, I can do.
request dot header and I can grab the content dash type and let's go back and send and we get this URL encoded that's the type Alright, we can also send raw JSON. So if I go ahead and get rid of that header and put in a different content type, we actually get a little drop down here. So content type, I'm going to set it to application slash JSON, go to body and instead of this URL encoded, I'm going to choose raw.
Okay, because we can send raw JSON. So name. And we'll say John Doe. And I'll go ahead and send, and I get application JSON because that's the content type. But again, I could access the body if I want.
So if I want to get rid of that and just do request.body and save and send that, we get our JSON of John Doe. All right, if we look at the headers, content type. Okay, so hopefully this is kind of making sense to you guys that don't have a lot of experience with this type of thing. Now, what about statuses? In Postman, if I make a post request to contact one and I send that, you can see that I get a status of 404. You guys all know what that means.
It's not found. And it just gives me this cannot post contact one. So we can send our own statuses. I mean, when we do a successful res.send or res.json.
it's automatically 200 but we can have conditionals and create different statuses based on that. So let's say that this route we actually need to have a name. If there's no name, we want to send back a 400 response, which means it's a bad request.
So I'll simply do an if statement here and let's say if not request dot body dot name. Then let's go ahead and do a res. I'm sorry, we want to return a res.status.
Okay, so this is how we can send a status code. And I'm going to send a 400. And then after that, we could do.json or.send. I'm going to do.send.
And I'm just going to say name is required. All right, now I'm going to go under the if statement. If a name is included, then, and typically you would do like, Some database stuff here. You would put the contact into the database or whatever. But I'm going to do a res.
And I'm going to do another status here of 201, which means that everything's okay and something was created. Okay, it means created. And I'll do a.send.
And then let's just do, I'll put a template string in here and say thank you. And then we can actually put in the request.body.name. All right, so let's save that. Let's go back to Postman.
And let's get rid of the name here. Let's not send it. And we get name is required, okay, because it's looking for that in the body, in the request body.
So if I send it, actually I'll just undo that. So if I say name John and I send, now we get thank you, John, because it passes. We're sending that request.body.name, okay. Let's see. So the next thing I want to look at is header values.
Now a lot of times when you're dealing with full stack applications, you use tokens or JSON Web tokens for for authentication and you send that you can either send it in the authorization. I like to send it in X off token in a value called X off token. So what I'll do here is create another route.
Let's do app dot. We'll do post to let's say slash login. All right. And then what I want to do here is check for a token in the header. So I'm going to say if there's no and then the way that we access header values already showed you this, we can do request dot header.
And then I'm going to check for X dash off. Dash token. Okay. So if that's not there, then let's send, let's send an error.
Let's do return. And one thing I want to mention is notice I did the return status here and not here. It's because you don't need it if it's the only or the last one, but if you have it before, if you have another response here, even if it's within an if statement that doesn't pass, you're going to get an error that says headers already sent. So make sure you use return up here.
Okay. So let's do return red. is dot status. And let's say if no token is included in the header, then we'll send a 400 and we'll just send an error that says no token. OK, now let's do a pretend validation for the token.
So I'll go ahead and just say if the request dot header X dash off. dash token let's say if that is not equal to the string of one two three four five six then it's going to be invalid so i'm going to return a response status of four or one, which is unauthorized. So I'll do send and we'll just say not authorized.
Okay. And then down here, if everything passes, we'll do a rez dot send and we'll say logged in. So we're just kind of simulating a login process.
Obviously it would be much more in depth. We need to use actual token, Jason web tokens and validate them and so on. But let's save that.
Let's try this out. So if we go back to postman, make a post request to slash login and we don't need any body data cause we're just dealing with headers and we can clear out content type. Let's just send that. So we get no token. Now I'm going to add a header value of X dash off dash token, but I'm going to to do one, two, three, four, five, which is wrong.
So we get not authorized. If I do one through six, we get logged in. Okay.
So just an example of, of how you can authenticate through, um, uh, tokens in the, in the headers. Okay. And by the way, if you're interested in, we do this in my Mernstat course, we do all this, this type of stuff. All right. So let's do, Let's simulate a put request.
So I'm just going to get rid of this. So for a put request, we would do app dot put and maybe it's like a blog post. So we'd have like slash post.
Now usually you'd have to identify which post you're updating and you would do that within the URL. So it would be like colon ID, which is like a placeholder. All right. And I know that we're doing a lot of express stuff, but my goal here is to just get you familiar with sending requests, body fields, header fields, dealing with that, sending status codes back. So here usually what would happen is we would do some database stuff.
So, database stuff to update the post and then send back a response. Let's do a res.json and we'll send the ID. Now if you want to get the ID that's passed in, you can actually use request.params and then whatever the param, in this case ID. And then the title we're going to send in the body, so I'll do request. Okay, so request params is going to access the URL values, request body will access the form data or the JSON data that you send in the body.
So we'll save that and from postman we can make a put request to slash and we'll do post slash 99. Okay, so this will get accessed with request dot params and then in the body. Since we're going to be sending data, we actually have to add a header value of content type. And I'm just going to send raw JSON.
So we'll do application JSON and then let's send the title. So title, my blog post. And if we send, we get a response back with the ID of 99 because that's what we put in here.
And then the title, that's what we put in the body. And I could put anything at all in here. So hopefully that just gives you an idea of how put requests work. But typically you would do an update of the database using that ID. And then delete would basically be the same thing.
So we just do app.delete and include the ID, delete it in the database and then return maybe most likely not going to return the post because it's deleted. So you might do something like a message. message and say post actually what we could do is we could say post and then take the ID and say deleted.
OK, so now for postman, we could make a delete request. We don't need any of this. We don't need this in the headers.
We could just send that we get post that deleted. All right. So yeah, I mean, hopefully this helps a little bit. Understand how this goes.
Now with Express, we can set a static folder. And this pertains to if you just have a static HTML website where you have a bunch of CSS files and JavaScript files and stuff like that. So in Express what we can do is we can actually set a specific folder to be our static folder.
And we do that with app.use. And in here I can just say express.static. And then here I can put the location of the folder, which is going to just be public.
So now in my folder structure, actually, I already have a public folder. I forgot I created that with an index HTML file that just says hello world. So I should be able, even though I don't have a route for my index page, I have this static folder. So that should load the HTML file. If I go to my browser, we can see it there.
And if I go to postman, we can see, oops, we want to make get to the index and now we can see the hello world. If I wanted to create like some CSS files in my public folder, I could do CSS and create style dot CSS and we'll just do like body, say background sky blue. So I'll save that. Let's create a JavaScript in our public folder as well. We'll say.
folder js and file main.js and i'll just do a console log of one two three i just want to include these files in my my html so back in my html i'll do a link to css slash style and then i'll link my javascript down here oops script source and js slash main.js All right, so I just want to show you that if I go to Chrome now and I reload in my network tab, I'm going to see all those files. Okay. They're all getting loaded.
We have our main document here, which has the content type of text HTML. We have our style sheet, okay. Text style. We have our JavaScript so we can see all that stuff.
We can also see the body of each one as well. Okay. And it would be the same if you had like some kind of shared host and you just uploaded your HTML and CSS and all that. You get the same type of thing here. And of course we can narrow the files down, CSS, JavaScript.
And if I had some kind of fetch request or Ajax request, that would show under XHR. So hopefully this gives you a good idea of how HTTP works. I know that we focused a lot on Express, but again I think it's a good example just because you have direct access to everything, to all the headers and body on both sides.
Now keep in mind when you deploy a Node.js and Express app, you're not going to serve it like this from port 5000. You're going to use something like Nginx, use a reverse proxy, and there's a whole bunch of configuration that goes into it. But as far as how HTTP works, it's the same way. You send data, receive data in the same way.
Alright, so thanks a lot guys. Thanks for watching. If you like this, please leave a like and I'll see you next time.