Laravel Form Request Patterns I Use in Every Project

Every time I see validation logic inside a controller method, I know that codebase is going to have inconsistencies. The same resource will have slightly different validation in the store and update methods. Error messages won't match. Edge cases will be missed.

Form Requests solve all of this, and they do more than most developers realize.

The Basics: Get It Out of the Controller

Your controller should never contain validation rules. Instead:

Your controller becomes trivially simple — just validate, call an action, and return a response:

Authorization in the Form Request

Most people return true from authorize() and handle authorization in middleware or the controller. But putting it in the Form Request means validation and authorization live together:

If authorization fails, Laravel automatically returns a 403 response. No extra code needed.

Conditional Rules for Store vs Update

Instead of two nearly-identical Form Requests, use one with conditional rules:

When creating, $productId is null and the unique rule applies fully. When updating, it ignores the current product.

Custom Error Messages That Help

Default error messages are generic. Custom messages tell the user what to do:

Preparing Input Before Validation

The prepareForValidation() method lets you normalize input before rules run:

This is perfect for converting currencies, generating slugs, or normalizing phone numbers.

After Validation Hooks

Need to do something after validation passes but before the controller runs?

The Rule: One Form Request per Action

Don't share Form Requests between unrelated endpoints just because the rules look similar today. They'll diverge over time. One action, one Form Request. Your future self will thank you.

Each Form Request should also have proper test coverage — happy path, authorization (403), and validation (422).