RESTful Route Design Review

[00:00:00]
>> Speaker 1: All right, welcome back So we just finished up locking down some of our routes with the authentication middleware that we created, verifying the JSON Web Tokens that we created upon login and sign-up Now let's create some of the CRUD controllers for some of the resources that we have, like habits, users, things like that, and that way you get a better sense of just how it all works together A request comes in

[00:00:00]
It gets routed to the right place along the way There's tons of middleware checking for authentication if that's what's needed, checking for input validation, and then finally reaching its destination to the controller to do the actual thing that it wants to do and then do the job and send back a response So that's what we're about to do—do those jobs So if we look at, I have this lesson here, lesson 10 for CRUD controllers

[00:00:00]
Let me make sure I checked out to a new branch Oh, yes, I did, okay We already talked about RESTful APIs and things like that I wrote a lot of that down here, so most of what I've been saying in the course about REST and CRUD is all here, just written down for you There are better resources to understand this This is just how it comes out of my head and the way I think about it Talked about like the route plus the verb, or you might hear method, route plus method and how that maps

[00:00:00]
One thing we've been talking about is HTTP status codes I wrote that down as well so you could think of HTTP status codes like this: anything in the 200 range is a success Anything in the 400 range is basically a client error So 400 is like, "Hey, invalid input." 401 is like you didn't send anything required for authentication—you didn't add that bearer token or API key, or whatever it is; it literally does not exist

[00:00:00]
403 might be you sent something, but it's wrong, so you're just not allowed 404 is like whatever you're asking for literally doesn't exist—that's not a route we have 409 might be like, "Oh, you're trying to create a user with an email that already exists"—so that might be a conflict But it's a conflict you would probably never tell the user about There's a status code for everything you can keep digging into

[00:00:00]
I promise you nobody uses anything outside of these, and even I would say 409 is somewhat rare So it's mostly just 200, 201 You almost never see 204 You'll see these 400-range errors all the time, for sure 500 means your server just crashed 502 technically means—if you're a CDN trying to access an origin and that origin is dead—it's not the CDN's fault, it's the origin's fault A CDN edge function is technically a gateway, so it's like, "Hey, I'm working, but the thing you want me to talk to is not working." And 503 is like, "Yeah, we know we're shut down for a reason

[00:00:00]
We messed up a migration, we've got to shut the server down." Which happens a lot Cool Alright, let's make these controllers There's a lot in here I have a controller for every single resource—we're not going to do all of them, but they're all mostly the same That's why there's really no point in doing all of them, but we'll go through at least one of the resources so you get an idea of what that looks like

[00:00:00]
I say we do the habit one I think that makes sense because we already did the sign-in and sign-up, so technically we already have users Now let's just allow users to create, read, update, and delete habits, and I think that would be good.