Dependency inject union type-hinted form request

[shaedrich]

Imagine, you have a webhook and you don't know if the request payload is

{
    "id": 1,
    "name": "John Doe"
}

or

{
    "error": "DuplicateEntry",
    "message": "A user with name John Doe already exists"
}

Currently, you'd create one request like this:

class WebhookRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'id' => [ 'int', 'required_without:error,message' ],
            'name' => [ 'string', 'required_without:error,message' ],
            'error' => 'string',
            'message' => 'string',
        ];
    }

But what if you could do just this:

class WebhookController
{
    public function inbound(UserCreatedRequest|UserCreationErrorRequest $request)
    {
        if ($request instanceof UserCreationErrorRequest) {
            throw new Exception("[{$request->error}] {$request->message}");
        }

        [ 'id' => $id, 'name' => $name ] = $request->validated();

        // …
    }
}

[henzeb]

Or, seperating the logic, register more controllers for the same route. That way you can also have multiple providers using the same endpoint. It would help in such situation to specify the source. Or a filter telling laravel which controller logic to use.

In your case it seems a whole lot of logic that does basically the same thing as invalid input response, but I may be missing something?

[shaedrich]

Or, seperating the logic, register more controllers for the same route. That way you can also have multiple providers using the same endpoint. It would help in such situation to specify the source. Or a filter telling laravel which controller logic to use.

Wait, one can register multiple controller for the same route? How would you achieve that? Via a middleware?

In your case it seems a whole lot of logic that does basically the same thing as invalid input response

It's just an example. Even though, it contains "error", it is not considered invalid by the application. Just because the other application that sent the webhook consideres it invalid, doesn't mean, this has to be treated the same way here. The example could be a variety of different code: Logging, making database entries, etc. This is not the same as if the validation failed.

[henzeb]

No, it is a suggestion. Because this is still checking which logic to use. If you could move that up to the Route framework it would help you separate the logic and make the code more clear.

[shaedrich]

Oh, you mean, instead of suggesting to Laravel to implement the union solution, I should suggest adding the option to add multiple controller actions? Yeah, that certainly sounds like an interesting suggestion 🤔

[macropay-solutions]

Hello. Usually all APIs have this situation and you check first if the response is valid and only then you validate it if needed.

This happens for the JS clients that can't handle properly non 200 responses only. For api to api the second case with error should not happen on 200.

[shaedrich]

For api to api the second case with error should not happen on 200.

Where and how exactly would you properly handle this for API to API?

This happens for the JS clients that can't handle properly non 200 responses only.

We are talking about incoming requests here, not outgoing responses—am I missing something?

[macropay-solutions]

@shaedrich apologies. You are right. These are webhooks.

It can be done without auto wiring the FormRequest in the controller:

/**
 * @throws \Throwable
 */
public function create(Request $request): Response
    if ($request->has('error')) {
        throw new \Exception($request->input('message', 'missing message');
    }

    // validate
   new WebhookRequest();

  // create

[shaedrich]

Looks more like a workaround than a solution to me. I know, that I can work around that, but a proper implementation would be nicer

[macropay-solutions]

A "proper implementation" would just "hide" the same logic in those 2 request classes, adding extra layers.

[shaedrich]

So I did a little research on what happens when a form request is passed into a controller method. And let me tell you two things: It's a whole lot and it's almost impossible to tap into that the way I suggested:

1. We have route in routes/*.php
2. Said route is bound to a controller method in app/Http/Controllers/*, where a form request from app/Http/Requests/* is type-hinted
3. When said route is accessed, several methods from the \Illuminate\Routing\ResolvesRouteDependencies trait, that \Illuminate\Routing\Route implements, get called via \Illuminate\Routing\ControllerDispatcher:
   1. ResolvesRouteDependencies::resolveClassMethodDependencies()
   2. ResolvesRouteDependencies::resolveMethodDependencies()
   3. ResolvesRouteDependencies::transformDependency()
4. From there, \Illuminate\Support\Reflector::getParameterClassName() is called, which doesn't deal with union types at all and—as the method name implies—only returns a single class or nothing (Interestingly, the class also has a method named getParameterClassNames() that actually deals with union types, however, it's not used in our case as far as I can tell)
5. When resolving the one(!) form request in \Illuminate\Foundation\Providers\FormRequestServiceProvider, Illuminate\Routing\Redirector is set on the form request as well
6. After resolving, the FormRequestServiceProvider immediately calls \Illuminate\Validation\ValidatesWhenResolvedTrait::validateResolved(), which—again, as the name implies—validates the form request right away
7. When it fails (which it would have to in order for the other part of the union type to be tried out as well), ValidatesWhenResolvedTrait::failedValidation() is called, which, in return, throws \Illuminate\Validation\ValidationException
8. ValidationException with $redirectTo set then is picked up by \Illuminate\Foundation\Exceptions\Handler::invalid() method that does the redirect (that's why we can't do anything else anymore if we have gotten this far)

So, essentially, because of 4 and 6 resp. 8, chances of getting it implemented as proposed by me are slim at best.

[shaedrich]

But fear not, I found another solution coming soon: