Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

kaarch's avatar

How to get custom Request class from the global request helper?

I know I can typehint a custom request class in a controller, but I noticed if I use the global request() helper elsewhere in the codebase it will only ever return a base instance of a Illuminate\Http\Request. Curious if there's a way to reference the same Request class injected into a controller without passing it through to multiple classes?

Edit: based on some of the replies so far, I see that my approach is not the best. Regardless, I’m curious why the Resource class has the request inject into its toArray method if it’s not to be used to modify the response array based on information contained in the request?

0 likes
12 replies
d8devs's avatar

Small Answer is: Service Container Binding

You can bind your custom request class to the service container and resolve it when needed.

For Example:

// in AppServiceProvider
public function register()
{
    $this->app->bind('custom.request', function ($app) {
        // Initialize your custom request class with global request parameters
        return new \App\Http\Requests\CustomRequest(request()->all(), request()->query(), request()->cookies->all(), request()->files->all(), request()->server->all());
    });
}

Wherever you need your custom request class, resolve it from the container:

$customRequest = app('custom.request');
1 like
kaarch's avatar

@d8devs Hm, that would work, but is not quite what I was hoping for. For context, I wanted to be able to add a match/switch statement to an API resource class that returns a different array representation per Request type. So something like (pseudocode)

public function toArray(Request $request) {
  return match($request::class) {
    StoreRequest::class => $this->toStoreRequestArray(),
    UpdateRequest::class => $this->toUpdateRequestArray(),
    default => $this->toDefaultArray(),
  };
}

It seems that I'll need to structure the code in a way that the Request class from the controller can be provided directly to the resource.

martinbean's avatar

@kaarch That completely defeats the point of API resources and having a consistent representation of data.

1 like
kaarch's avatar

@martinbean I’m curious then why the resource class has the request injected and has so many if and when type conditional methods if not to differentiate the response based on different conditions, including ones based on the request being made?

martinbean's avatar

@kaarch Why are you trying to use an API resource for multiple “requests”, but then trying to have two different code paths depending on the request? Why does the request change how the entity should be displayed?

The idea of API requests is to say, “this is what my X entity looks like, and will look like everywhere it’s presented.” Not, “this is my X entity, but for request A it looks like this, for request B it looks like this, for request C it looks like this…”

kaarch's avatar

@martinbean in this case, it’s for a PWA, so it is an API, but for internal access/use, not public. And for this use case, the index method for this model only needs to present the IDs to the front end. Other methods need more complete representations, including relationships, etc.

There are several ways to achieve the above, and I don’t have any concerns about being able to or how I will; now I have more of a question of understanding why? Why Laravel offers a pattern to create custom request objects (primarily, if not exclusively for validation), why resource objects are injected with an instance of the current request, but why those two seemingly related concepts are technically and/or philosophically mutually exclusive?

martinbean's avatar

@kaarch Well from your description, it sounds like you want two resources then: a “simple” resource and a “detailed” resource.

Snapey's avatar

You shouldn't really be using the request class outside of the controller

kaarch's avatar

@Snapey I asked the same question above; if not, why is the base request injected into a resource’s toArray method if I’m not supposed to be using it outside of the controller?

puklipo's avatar

request() can be used outside the controller. But only in Http context.

FormRequest is used for validation. Never use it outside of a controller. If you really want to use it...

$request = FooFormRequest::capture();

Resources request is used for the authenticated user.

public function toArray(Request $request): array
{
    return [
        'id' => $this->id,
        'name' => $this->name,
        'email' => $this->email,
        'secret' => $this->when($request->user()->isAdmin(), 'secret-value'),
        'created_at' => $this->created_at,
        'updated_at' => $this->updated_at,
    ];
}
kaarch's avatar

@puklipo that distinction between the purpose of a FormRequest clears things up a little bit… but if the request in a resource is only for the user, why pass the whole request and not just the user?

Is it similarly a bad practice to check the request for query parameters? In the past I’ve either loaded a relationship or not based on a request parameter…

Please or to participate in this conversation.