Why Resource controllers in Laravel? - Purpose & Use Cases

The Big Idea

Discover how one simple line can replace dozens of repetitive routes and methods!

The Scenario

Imagine building a web app where you must write separate methods for creating, reading, updating, and deleting items manually in your controller.

You have to write repetitive code for each action, and link each route to the right method yourself.

The Problem

This manual approach is slow and error-prone because you repeat similar code for each action.

It's easy to forget to add a route or mix up method names, causing bugs and wasted time.

The Solution

Resource controllers in Laravel bundle all common actions (index, create, store, show, edit, update, destroy) into one controller.

Laravel automatically sets up routes for these actions, saving you from repetitive code and mistakes.

Before vs After

✗ Before

Route::get('/posts', [PostController::class, 'index']);
Route::post('/posts', [PostController::class, 'store']);
Route::get('/posts/{id}', [PostController::class, 'show']);
// and so on for each action

✓ After

Route::resource('posts', PostController::class);

What It Enables

It enables you to build clean, organized, and maintainable controllers quickly with all standard actions ready to use.

Real Life Example

When building a blog, resource controllers let you handle all post-related actions in one place without writing repetitive route definitions.

Key Takeaways

Manual route and method setup is repetitive and error-prone.

Resource controllers group common actions in one controller.

Laravel auto-generates routes, saving time and reducing bugs.

Practice

1. What is the main purpose of a resource controller in Laravel?

easy

A. To create views without a controller

B. To handle database migrations automatically

C. To group all CRUD actions for a resource in one controller

D. To manage user authentication only

Solution

1. Step 1: Understand what resource controllers do

   Resource controllers in Laravel group related actions like create, read, update, and delete (CRUD) for a resource in one controller class.

2. Step 2: Compare options with this definition

   Only To group all CRUD actions for a resource in one controller correctly describes this grouping of CRUD actions. Other options describe unrelated features.

3. Final Answer:

   To group all CRUD actions for a resource in one controller -> Option C

4. Quick Check:

   Resource controller = CRUD grouping [OK]

Hint: Resource controllers group CRUD actions in one place [OK]

Common Mistakes:

• Confusing resource controllers with migrations
• Thinking resource controllers handle views alone
• Assuming resource controllers manage authentication

2. Which of the following is the correct syntax to register a resource controller named PostController for the route /posts?

easy

A. Route::resource('posts', PostController::class);

B. Route::controller('posts', PostController::class);

C. Route::get('posts', PostController::resource());

D. Route::resource('PostController', 'posts');

Solution

1. Step 1: Recall Laravel resource route syntax

   The correct syntax uses Route::resource('uri', ControllerClass::class) to register all resource routes.

2. Step 2: Check each option

   Route::resource('posts', PostController::class); matches the correct syntax. Route::controller('posts', PostController::class); uses controller which is different. Route::get('posts', PostController::resource()); is invalid syntax. Route::resource('PostController', 'posts'); swaps parameters incorrectly.

3. Final Answer:

   Route::resource('posts', PostController::class); -> Option A

4. Quick Check:

   Resource route syntax = Route::resource(uri, Controller::class) [OK]

Hint: Use Route::resource('uri', Controller::class) to register resource routes [OK]

Common Mistakes:

• Using Route::controller instead of Route::resource
• Swapping URI and controller parameters
• Calling resource() as a method on controller instance

3. Given this resource controller route registration:
Route::resource('photos', PhotoController::class);
Which URL and HTTP method will call the destroy method in PhotoController for photo with ID 5?

medium

A. PUT /photos/5/destroy

B. GET /photos/5/destroy

C. POST /photos/5/delete

D. DELETE /photos/5

Solution

1. Step 1: Recall resource route conventions for destroy

   The destroy method is called with HTTP DELETE on the resource URI with the ID, e.g., DELETE /photos/{id}.

2. Step 2: Match options to this pattern

   DELETE /photos/5 matches DELETE /photos/5. Other options use wrong HTTP methods or incorrect URLs.

3. Final Answer:

   DELETE /photos/5 -> Option D

4. Quick Check:

   Destroy = DELETE /resource/{id} [OK]

Hint: Destroy uses DELETE method on /resource/{id} URL [OK]

Common Mistakes:

• Using GET or POST instead of DELETE for destroy
• Adding extra path segments like /destroy or /delete
• Confusing PUT with DELETE method

4. Consider this route registration:
Route::resource('users', UserController::class);
Which of the following code snippets will cause a runtime error when trying to access the show method?

medium

A. public function show() { return 'User not found'; }

B. public function show(User $user) { return $user; }

C. public function show($id) { return view('user.show', compact('id')); }

D. public function show($id) { return User::findOrFail($id); }

Solution

1. Step 1: Understand show method parameter requirements

   The show method expects either an ID parameter or a model instance via route model binding.

2. Step 2: Analyze each option

   public function show() { return 'User not found'; } has no parameter, so Laravel cannot pass the required ID or model, causing a runtime error. Others have correct parameters.

3. Final Answer:

   public function show() { return 'User not found'; } -> Option A

4. Quick Check:

   Show method must accept ID or model parameter [OK]

Hint: Show method needs parameter for ID or model [OK]

Common Mistakes:

• Omitting parameters in show method
• Using wrong parameter types without binding
• Ignoring route model binding requirements

5. You want to create a resource controller for Product but only want to generate routes for index, show, and store methods. Which is the correct way to register this in routes/web.php?

hard

A. Route::resource('products', ProductController::class)->except(['create', 'edit']);

B. Route::resource('products', ProductController::class)->only(['index', 'show', 'store']);

C. Route::resource('products', ProductController::class)->skip(['create', 'edit']);

D. Route::resource('products', ProductController::class)->filter(['index', 'show', 'store']);

Solution

1. Step 1: Recall how to limit resource routes

   Laravel allows limiting routes using the only method with an array of method names.

2. Step 2: Evaluate each option

   A uses except(['create', 'edit']) which excludes only create and edit, leaving index, store, show, update, and destroy. B correctly uses only(['index', 'show', 'store']). C and D use invalid methods skip and filter.

3. Final Answer:

   Route::resource('products', ProductController::class)->only(['index', 'show', 'store']); -> Option B

4. Quick Check:

   Limit resource routes with only([...]) [OK]

Hint: Use ->only([...]) to limit resource controller routes [OK]

Common Mistakes:

• Using invalid methods like skip or filter
• Confusing only with except
• Not passing array to only method