Transcript from the "Custom Header & Status Code Exercise" Lesson
>> Jem Young: What's this arrow that I'm pointing to here? Can anybody tell me what that is? Yes.
>> Speaker 2: It's the response code?
>> Jem Young: Yeah, it's a status code. And status codes are another thing that we take for granted, but we probably know some of them. Does anybody know any funny status codes?
>> Speaker 3: I like the HTTP status cats, the 405.
>> Jem Young: Those are pretty good. There's a lot of like status code memes out there. Yeah?
>> Speaker 2: I am a teapot.
>> Jem Young: Yeah, that one's a good one. Status code 418. I love that one. It doesn't mean anything. But it exists and it's part of the official standard.
[00:00:30] There's probably a funny story behind it. But I don't know what it is.
>> Speaker 2: Enhance your calm.
>> Jem Young: Hm?
>> Speaker 2: Enhance your calm, 420.
>> Jem Young: Is that an actual status code?
>> Speaker 2: It's a Twitter one, yeah.
>> Jem Young: [LAUGH] I guess people can make up their own status code if you have enough clout.
[00:00:42] I don't know.
>> Speaker 2: I heard [COUGH] there's an IoT device teapot that returns the teapot code now actually.
>> Jem Young: You can do whatever you want now with the status, that would be a good one. Actually, we should do that.
>> Speaker 2: I think it exists. [LAUGH]
>> Jem Young: Maybe we'll make an exercise that does that.
[00:01:01] You hold that thought.
>> Jem Young: Let's talk a little bit about status code. What a status code does is it indicates the status of the HTTP request. Because there if you make a request and response, there's always going to be a response back. But you don't know what to do with that response without the status code.
[00:01:16] For instance, a status code of 401 means you're not authorized. That generally means you're not logged in. But really what a status code does is it helps the web application in the browser know what to do with that response. Because without all of these status codes, it would just be like, everything's okay.
[00:01:33] Everything's okay. Everything's okay. But a 401 the browser can handle specifically and even better, your application can handle specifically. So what's a 404? I mean, we say 404 page all the time. What does that mean?
>> Speaker 3: Not found.
>> Speaker 2: Not found.
>> Jem Young: Not found, exactly. And so all these prefixes, so the 1, 2, 3, 4, 5, all mean something very specific.
[00:01:52] 1, anything starting with a 1 is just an information. There's not much you wanna do with it. For example, status code 101 just means continue. It means there's probably more data coming, and just hold on for a second. 200s means success. So different types of 200s mean it was successful depending on what it is.
[00:02:13] So general success, like nice job, this response is valid, is 200. If the post was successful, it'd be something like 201, or something like that. And so on and so forth. You don't really need to know every single status code, but it's good to know what these prefixes mean, so you know immediately what's going on.
[00:02:29] The threes we talked about, 301 moved permanently, 302 temporary redirects. 300 status codes are always redirects. The 400 are some sort of client error. So it means you did something wrong, as in you've sent a malformed request, you weren't logged in correctly. You're trying to request a page that doesn't exist, so a 404 page.
[00:02:50] Those are always client errors. So if you see a 404, that means you did something wrong. If you see a 500, that means something on the server's wrong. 500s are the ones you don't wanna get. Because you should never be in a state where you're returning 500s, because that means either your application is bad or the route's bad, or the server is on fire somewhere.
[00:03:07] But it just means there's a server error and we didn't know how to handle it. And servers should always handle their own errors and then return something else to the client. Yes?
>> Speaker 2: I was gonna say, if you're a front ender, then actually 500 is a good answer because you know that you didn't break it.
[00:03:22] You know that it's somebody else's problem to deal with, theoretically.
>> Jem Young: That's a good point. 500 is someone else's problem. 400, your problem. Think of it that way. But these are just good things to know as web developers that we probably don't think that these things have meanings to them.
[00:03:37] But they all mean something. For instance, what does Amazon have, like a famous 404 status page. You know, they have like Amazon dogs, people do fun things with 404s when you try to request bad paths. And if you wanted to, we can write our client application so that instead of seeing a server error, which is a bad thing, especially if someone's paying you money and you're returning 500s, that means you're doing something wrong.
[00:04:02] You can handle that on the client side and say like, I'm getting 500, just be like, hey, something went wrong. We're working on right now, rather than just like that ugly 500 page. So it's good to know how to read and handle status codes. So just a quick quiz.
[00:04:17] What's the proper status code for a successful POST request?
>> Speaker 2: 200.
>> Speaker 3: Created, or.
>> Jem Young: Yeah, 200 works. That just means, okay. Or 201 means created, it means successfully created. Nice. Now you kind of get in. It's like when you start thinking at this level, you start thinking about that kind of senior engineer thinking about how to structure your application and not just blindly accept and return status codes, things like that.
[00:04:43] So let's do an exercise where we create a custom header and a custom status code. So in your app, that app we created yesterday which should be up and running, create a path that returns 418, which is I'm a teapot, and a custom header. And remember, custom headers start with X.
>> Jem Young: There's a hint at the bottom if you can't see in really small. To set a status code on the request, res.status. That's the response.status. To set a header, res.set.