Inline Controller Validation vs. Laravel Form Requests

When a Laravel route receives submitted data, validation checks the values against rules before the controller saves or uses them. You can put the rules in the controller method that handles the request, or move them into a dedicated class called a form request. A controller handles a route; a form request is a Laravel request class that checks input and can authorize the person making the request.

Both approaches use Laravel’s validation system and can return errors to the user. Inline validation keeps a short set of rules beside the controller action that uses them. A form request puts the rules in a separate class, and Laravel runs them before the controller method. Choose the location that makes the rules easiest to understand and maintain, and pass only validated data to the code that saves it.

Where validation runs

With inline validation, the controller calls $request->validate() where it wants validation to happen. Laravel checks the submitted data against the rules at that point. If validation succeeds, the call returns the validated values and the controller continues. If it fails, Laravel stops the controller action and handles the validation failure.

public function store(Request $request)
{
    $validated = $request->validate([
        'name' => ['required', 'string'],
        'email' => ['required', 'email'],
    ]);

    // Save or pass $validated to the next layer.
}

With a form request, the route or controller lists the request class as a method parameter. Laravel creates the form request and runs its validation before calling the controller method. The rules live in the class’s rules() method, so the controller can focus on what happens after validation. Form requests can also contain authorization logic, as described in Keeping Laravel Controllers Clean with Form Requests.

public function store(StoreUserRequest $request)
{
    $validated = $request->validated();

    // Save or pass $validated to the next layer.
}

The StoreUserRequest class defines its rules in rules(). Laravel rejects invalid input before store() runs. If rules depend on values in the URL or other details in the request, a form request can use those details when building its rules; see this discussion of form request rules with parameters.

How Laravel returns validation errors

For a traditional web request, Laravel redirects the browser back when validation fails and makes the error messages available to the page. This happens whether the controller called $request->validate() or Laravel validated an injected form request. Laravel validation best practices also describes how form requests handle validation failures and redirects.

When a request expects JSON, Laravel returns validation errors in a JSON response with an HTTP status code that signals an error. The client can display the messages beside the relevant fields. A form request can customize its failure response by overriding failedValidation(), for example, when an endpoint needs a specific JSON error format, as described in the form request validation guidance.

Which approach fits the action

Inline validation fits a controller action with a short set of rules used only there. The rules appear beside the code that uses them, so readers can scan a small action without opening another class. If several controller methods repeat the same rules or the rules grow lengthy, move them into a form request. That gives the rules a clear home and lets each controller focus on its action.

A form request fits validation that needs a clear name and its own class, especially when it includes authorization checks or rules based on request details. For example, a StoreUserRequest tells readers where to find the rules for creating a user, while the controller handles the validated data. This separation also makes it easier to review or test validation on its own.

With either approach, pass validated values to a service or use them to save a record. In a form request, call $request->validated() rather than $request->all(). The all() method includes submitted fields that the rules did not validate; validated() returns only the accepted data. Laravel Form Requests Are Not Finished Until You Call validated explains this distinction.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com