This course has been updated! We now recommend you take the API Design in Node.js, v4 course.
Transcript from the "Exercise 2 Solution, continued" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Speaker 1: The put, little trick here. Lot of stuff going on here. So put is, let's go back and look at our blueprint. [NOISE] Get out of here. It should update and return the matching line with the posted update object. So that means there's one, I'm expecting an object to come in from the client with some properties that I need to first find a line with a matching ID and if I do, update that line with the object I was given.
[00:00:35] So I'm doing a few things here. One, first I'm gonna grab the update. Which is on rec.body. So that can be an object with any property on it that we want to update the line with. So the name, the pride, the age, the gender. Pretty much anything but the ID.
[00:00:47] And then just for a safety check, just in case you tried to update the ID, I'm just going to delete the ID. Just in case you tried to update the ID. So we don't have things with two the same ID's and stuff like that. You don't want to change the ID, the database is in charge of ID stuff.
[00:01:03] So I deleted the ID of the update objects just in case you put that there. You don't have to do that but it will fix some errors. And then what I'm doing is I'm just going to search to see given the ID that you sent me here, if that line exists in our database.
[00:01:20] Which is just an array, so I'm using the find index method of load ash, which takes in an array and some object. If it finds an object in that array that matches these specific parameters it will return the index of it. So that's why I'm able to say, hey is this index in this line, does it exist?
[00:01:41] If it does not exist, then just send nothing. Just stop. Just don't do anything. Don't even try to update. If it doesn't exist. If it does exist, then this assign thing is just like an extend. Extend those two objects. So take the update object with the new properties on it and extended on the old object.
[00:01:58] Does anybody not know how extend works? It's just merging two objects. So, it's going to merge the object on the right to the object on the left. And then it's going to return the object on the left. So it's like, yeah if you found the lion, which is referenced as the lions array.
[00:02:16] This in an index right here, this is a number, and this is the object that they sent on the put request. Merge those two and send it back. So this right here is updating it inside the array and it's giving it to us as a reference to return.
[00:02:34] So it's doing the two things in one line. Yes.
>> Speaker 2: There's a question on what's your view on updating UI with the new item instantly on the client and then rolling back if the server does return in error.
>> Speaker 1: Yeah, so if the server returns in error, then you definitely want to roll back.
[00:02:50] So the way you would have to handle that, that's a good question, That's definitely client side related. So the way you do that is, so this is the thing that I'm using to update with the post you would come down here and do something .catch, if you're using promises.
[00:03:07] And you say, okay on .catch so you're like you know handle the error here. So yeah if the server responds back than an error then you have a seat when update the UI. The server wouldn't even send back the object that was created, so you couldn't even update the UI if you wanted to, you wouldn't even have the object.
[00:03:22] So yeah definitely don't update the UI or don't add any type of object there until it comes back, it'll probably show an error message or something like that or whatever you wanted to do. Or gracefully try again if it's a specific error message.
>> Speaker 1: Cool, yeah so I sent back that updated line.
[00:03:40] And then just listen on the port and that's it for the solution. Any questions?
>> Speaker 2: Did you make a delete route?
>> Speaker 1: Yeah actually I saved the delete route so we could do it in person. Yeah. So, any questions on this? No? Okay. So, the delete route. Yeah, I want to do this one in person.
[00:04:02] So if you haven't found out already, all we have to do is just use the AGCP verbs. Get, put, post, delete. So, app.delete, we know is going to be lions/: ID, function. And we're going to take a request and response. So the first thing we need to do is find the index.
[00:04:29] So what I'll do is, I'll just grab this, up here.
>> Speaker 1: So and I'll do the same thing I did before. If we couldn't find the lion the just do the res.send just don't do anything
>> Speaker 1: Else. If we did do it then we need to splice it or I'm sorry lions.splice.
[00:04:53] At that lion index one. And then do a res.json or actually I should say the reference verse, so var deletedLion = lionslion then splice it. And then Send it back. So that's the deleted route.
>> Speaker 1: So first I'm gonna find it by index. If it doesn't exist, don't try to delete anything, just stop.
[00:05:25] You could think of like when you could only respond once inside of a function. Once you respond, you can do no more executions. Almost like a return statement. The JavaScript's still gonna go execute but you cannot do another response. If I do res.send here, and right below it's like res.json, it won't work and in fact express might even throw errors like you can't you already did that.
[00:05:48] You already try to write the head you can't write it again.
>> [SOUND]
>> Speaker 1: So just remember that, you can only respond once and any stack. So even if I have a whole bunch of middle ware here I can still only respond once not per function but per request you can only respond once.
[00:06:10]
>> Speaker 1: Yeah, so that's delete.
>> Speaker 1: Any questions on this stuff, yeah?
>> Speaker 2: I got two questions. First one, sometimes you see like these object responses where they have like all this other data of like what was the response 200 and other things that they tag along.
>> Speaker 1: Right.
[00:06:31]
>> Speaker 2: Do you think that is a good idea, is that like a best practice, or just some people?
>> Speaker 1: You mean have the server send all that stuff back to the client, or are you saying?
>> Speaker 2: I'm saying, in some API's that they put more properties around their requests.
[00:06:48] They don't just return the object you changed?
>> Speaker 1: Right.
>> Speaker 2: They'll add some other attributes and then you can do like change object is one of the I see what you mean, so like having the API send back a more informed resource. Yeah.
>> Speaker 1: That's kind of like a couple of things.
[00:07:03] One, the resources are probably a lot huger than our simple line read, resource so there's tons of more native properties on that object. And then two, they probably are like an API as a service, so they need to send specific information, like maybe your rate limit or specific things like maybe you're hitting pagination and they want to show you what page you're on or what cursor you're on.
[00:07:25] So depending on the API you will see a lot of different things. But like if you're building an API for your application you probably won't have a lot of that stuff right, because you aren't building your API as a service for people to use. You're just building it for your application, so probably only send back what your application needs to cut the wait down for what's sending across the wire
[00:07:44]
>> Speaker 2: Okay that makes sense. And then my second question is, if we were pushing this to production on a put route, would we validate the fields that they're trying to update, like they could add any fields to our extend.
>> Speaker 1: Right, and that's where the data's gonna come in on our schema, we do the validation there.
[00:08:02]
>> Speaker 1: But that's like the last place you do validation. You should be validating on the front end like, you should have JavaScript validate before you Since to the server first.
>> Speaker 2: But you wouldn't validate in the route, you would validate in the database.
>> Speaker 1: Yeah I validate in the database, I'll let it try to save.
[00:08:18] And let the database do its validation, which is way more powerful than something I could probably write.
>> Speaker 2: Yeah, more efficient, that makes sense.