This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "Express Response Object" Lesson
>> Scott Moss: So we'll talk about how to actually end, or finalize, some of those things. So what we'll do is we'll go over to, let's go to one of our routers. Let's go to the item router here. So if you're in the item router,
>> Scott Moss: Let's talk about some of these.
[00:00:18] So I'm gonna make some controllers here inside the get request. So I'll say request and response. And we'll just talk about how to do some stuff inside this controller. So we already looked at this response object and it got some stuff on it like we used res.send before which allows us to send some types of arbitrary data.
[00:00:36] We have a lot over here on the response object that we could use inside of our controller. One of the most useful ones is gonna be res.status. This is new to Express, or I wouldn't say new, but it's newer. But this allows us to set the status code of the response that we wanna send back, right?
[00:00:55] So if we wanted to do a 200, if we wanted to say it was a 404, we could do whatever we want here. So this allows us to set that status code. We're not responding, we're just setting the code before we respond. Any time you wanted to end this response you could just do .end like that.
[00:01:13] Even right on the response object itself. You're gonna say, just end this and it'll stop. It'll just cancel the requests. So at any point you could do that. There'd be no message that's sent back or anything. You'll just end it. But status is a good one. It's chainable.
[00:01:26] It always returns the response object itself so that way we can chain it with a .end like this or, from what you've been using, you could do a .send. So if you want to send back a message after it was 404 of whatever you wanted to do, not found, you could do that.
[00:01:44] Set whatever status you want here, so status is a good one, send is pretty good. Send is smart enough to know, well, it attempts to figure out what type of data you're sending it. Whether it's JSON, whether it's string, whether it's some type of file, it tries to get smart about it but it's not the best, so there are explicit ways to do that.
[00:02:04] So for instance we can just do .json, which is explicitly saying I want to send back some json, and it'll set the appropriate json headers and stuff like that to make sure you send it back. But most of the time, because this is an API server that's always serving json, you can do .send and it's smart enough to know that you're sending back json so it'll convert it to json to figure it out.
[00:02:24] But if you were serving static assets or anything like that with no real experience, which I highly don't recommend, then you couldn't do dot send. And you have to set the mime type, you might have to set some different headers. That way the browsers and other clients can read those type of files.
[00:02:59] So because I didn't put a return here, there's nothing stopping you for writing more code underneath it. The only problem is Express is not expecting you to do that. So if you do add some more code underneath it you almost likely will have some bugs. And if you're intentionally doing it because you think you're doing something clever, don't do that [LAUGH].
[00:03:19] So get in the habit of thinking of a response as a retur. And it's like there's nothing after this. This is it. If you have some if statements and some branches, that's cool, but at any point after this, just don't do anything. In fact, you can have this put in your return here if that helps you feel better.
[00:03:35] But yeah, there's nothing stopping you from like going here. Like some people, this is where they will like, I'm gonna get clever and like after I send back a response, this is where I want to do my analytics and stuff like that, that's cool. There's some scenarios where I can think of where you would right code after you send back a response.
[00:03:50] Like if you were responding to web hooks. Right cuz if you're getting let's say stripes, stripe is sending you web hooks for payment information from your clients. Like updates on their payments information. When you have a server that responds to webhooks, you have to reply immediately. You don't want the webhook sender waiting for you to process their webhook, for you to respond to them.
[00:04:09] So as soon as you get an incoming request from webhook, you're like, cool, I got it. And then you wanna continue to do what you were doing. So that's one example I could think of where you would do that, is you wanna hear the respond immediately, but then go ahead and process what you were going to do with that webhook.
[00:04:22] So that's a good example. Another good example is, actually, that's the only good example I can think of, [LAUGH], I wouldn't do that anywhere else. It's very complicated, for somebody to look at and kinda understand what's going on. Especially when you start doing stuff like this, not that, but this.
[00:04:41] Now, you added a next() after there, it's like, okay Whats really happening,like I cant tell whats happening there. So, you get problems. The other thing is, once you send back a response, for a request, and you try to send back another response right after it, you'll get error from express saying response already sent.
[00:05:00] So you cant send it again .It will just tell you, you already did that. Can't do it again. So, just be careful of that. That's a big gotcha that I run into all the time. Any questions on the response of it?
>> Scott Moss: No, okay, cool. And again, there is this a lot more stuff here that's appropriate for different other types of APIs, and might be appropriate for JSON APIs, but for most of the time, you're just gonna be setting a status, setting back a payload, and that's about it.