Closed philbates35 closed 8 years ago
Laravel's Form Request is its own data exchange protocol (data format - forms (not json) and it has its own agreement on redirects and HTTP return codes). If you like the approach IMO the proper way is to create JsonApiRequest
extending Request
and implementing ValidatesWhenResolved
.
ValidatesWhenResolved
has only 1 method validate
which implements all logic around validation, redirects, exceptions and etc.
and of course it should be supported in a ServiceProvider
similar to vendor/laravel/framework/src/Illuminate/Foundation/Providers/FormRequestServiceProvider.php
Thinking about it, that does seem like the way to go. However, one important point I tried to get across in the original post (probably very badly) is that at that at the point of a form request, I'd like a way to easy access what is currently received from JsonApiTrait::getDocument()
. Right now, I'd need to create a JsonApiRequest
class that uses JsonApiTrait
, and calls $this->initJsonApiSupport(app(IntegrationInterface::class));
in the constructor (note that this would be done again immediately after in the controller too if validation passes), when all I really want is to access the decoded Json Api document array so I can perform simple validation. Does that make sense?
Requests similar to Laravel's are added. They could be used for attributes validation. If not only attributes but relationships should be validated it's better (easier) to do on API level. Samples for both approaches are included.
In the examples in the readme, all validation is handled within the controller directly. I'm trying to use Laravel's Form Requests, but it doesn't work nicely with the way your JSON API packages work.
The Laravel Form Request class passes the result of
Illuminate\Http\Request::all()
into the validator class it creates. I think it would be ideal to have the flexible to parse the decoded JSON API document (i.e. the array returned fromNeomerx\Limoncell\Http\JsonApiTrait::getDocument()
) within the form request class - however, you only have access to theJsonApiTrait
at the controller level, whereas the form request class is one level lower meaning in the form request you don't have access toJsonApiTrait::getDocument()
.I was able to kind of make it work by making a new
JsonApiRequest
class that extended Laravel'sFormRequest
class and used theJsonApiTrait
(initialised on construction) in my new class, but that solution fails when the header fails validation or there are parameters in the URL - again, this is because in the FormRequest we are a level lower than the controller so when the integration is initialised in my FormRequest class header / parameter validation fails because, for example,$allowedIncludePaths
has not yet been set.I think the solution would be involve having a way to be able to access to the decoded JsonApiDocument any where in the application without having to validate headers / URL parameters at the same time (which is what happens when you use the
JsonApiTrait
. Then, I could inject / locate in the container that class in my FormRequest classes, and only check headers / URL parameters in the controllers.For reference, here's my hacky attempt at making an abstract JsonApiFormRequest class (that my other JSON API form request classes would extend from) that works with your packages (but remember it's triggering URL parameter / headers validation which I don't want to happen at this point!). Hopefully this will make what I'm trying to say clearer:
And here's a concrete form request class that extends from my new base class: