I'm sure you've run into this before. Imagine you set up an endpoint to view a Post, we'll accept that, and then simply return it as JSON. Now, if I open the terminal, you can see I have two posts at the moment. Let's take a look at the first. If I run it in the browser, sure enough, I get the appropriate record. However, I have a slug here, and I want that to be the identifier in the address bar. Well, until Laravel 7, here's what you had to do. You'd have to visit your Post model, and then override a method called getRouteKeyName. This effectively returns the column name that Laravel should use for that route model binding.

You'd have to visit your Post model, and then override a method called getRouteKeyName. This effectively returns the column name that Laravel should use for that route model binding. In this case, it'll be slug. So now, rather than tracking down the Post by its ID, we'll track it down by its slug. So if I come back to Firefox, let's copy that slug, and I give it a refresh, it's not going to work, right? Because we're not tracking the Post by the ID anymore, we want the slug. And now it works. Okay, well, in Laravel 7, you don't have to do this if you don't want to. I can remove it, and of course now it fails again.

Okay, well, in Laravel 7, you don't have to do this if you don't want to. I can remove it, and of course now it fails again. But if I return to my routes/web.php file, all I have to do is add a colon, and then the name of the key. In this case, slug. Track down the post using this key. And now if I come back and refresh, it works. Super useful. All right, let's extend this, though. Sometimes you'll want to scope a search to a parent model.

All right, let's extend this, though. Sometimes you'll want to scope a search to a parent model. So for example, track down this specific User, and then of their Posts, I want this specific one. And then we'll accept the User, like so. All right, well, this will actually work how we want, but traditionally, it wouldn't have. So let's remove this just for a moment and take a look in the browser. Now if I visit this endpoint, sure enough, I see the Post. And the user_id for the Post is 1, which means we're good. However, if I access Post with an ID of 2, I can access that as well, and this no longer

And the user ID for the post is 1, which means we're good. However, if I access post with an ID of 2, I can access that as well, and this no longer makes sense. I'm trying to find the post with an ID of 2 that was created by the user with an ID of 1, but it wasn't, even though it still works. And usually, you don't want that, and it's an easy trap to fall into. I've done it myself. So again, in the past, you might scope it by saying, well, give me the user's posts, and then I'm going to be explicit that I want this specific post. So now if I come back, though, sure enough, the user with an ID of 1 can view their own

and then I'm going to be explicit that I want this specific Post. So now if I come back, though, sure enough, the User with an ID of 1 can view their own posts, but if they try to access a post they didn't create, it doesn't work. All right, well, once again, in Laravel 7, you no longer have to do this. So let's bring it back to what we had before, come back, refresh. It works, even though it shouldn't. And now if I set the key name here, even if it's still the ID, even though that's the default, adding this here will change the behavior. And now if I come back and refresh, we no longer have access. But we do have access to this one.

And now if I come back and refresh, we no longer have access. But we do have access to this one. So now we can see, when we set a custom key name here, behind the scenes, Laravel will scope this to the parent model using a basic convention. For example, all right, we need a User, and then we have a Post here, so you probably want the Post's relationship on User, and we can find that here. It'll reference that relationship to scope the Post to that User. Okay, so now the only remaining step is we're going to switch back to using a slug, and then let's grab one of these here. How about this one here?

then let's grab one of these here. How about this one here? Let's visit post/slug, and it works. However, if we try to grab a different slug that was not created by that User, it's not going to work. You have to have created the Post to view it. So just remember, to make this scoping work, you have to set a custom key here.