Why is validation process executed on `kernel.view` instead of `kernel.request` ?

[jdeniau]

I am upgrading a pretty "custom" API from v1 to v2, and thus I have a lot of "symfony-style" controllers.

I ask myself why do validation process appear after the "controller" (or action) ?

As I see it, I think I will need to "duplicate" the validation logic to appear before the controller code appends (at least the configuration), because the controller contain the core logic (saving stuff to persistance layer, etc.)

Am I missing a reason for that ?

Thank you

[jdeniau]

Well a good night sleep helps so it's logic that validation appends just before persist too, in case you did alter the object properties in the controller. But it can be interesseting to validate input data, isn't it ?

[soyuka]

#554 ? I think we discussed this in another issue can't find where though :|

[jdeniau]

Regarding this question, and if I understand api-platform right, I think it's maybe weird, but the controller / action place is really "custom-logic", and thus overriding the controller / action may be a bad practice. In fact it is said in the documentation to prefer event system against action / controller.

In fact in my case, I "simply" need to put my logic "somewhere between the validation and the persistance", but as a lazy developper, I just want to use the easy way, wich is the controller (and the controller allow to add anotations for routing, etc., wich is quite usefull).

[soyuka]

Regarding this question, and if I understand api-platform right, I think it's maybe weird, but the controller / action place is really "custom-logic", and thus overriding the controller / action may be a bad practice. In fact it is said in the documentation to prefer event system against action / controller.

This is correct.

In fact in my case, I "simply" need to put my logic "somewhere between the validation and the persistance", but as a lazy developper, I just want to use the easy way, wich is the controller (and the controller allow to add anotations for routing, etc., wich is quite usefull).

In this case I usually just uses the DataProvider:

#- routing.yml

api_foos_by_domain:
    path: /api/foos/by_domain
    defaults: {
        _api_resource_class: AppBundle\Entity\Foo,
        _api_collection_operation_name: api_foos_by_domain,
        _controller: ApiPlatform\Core\Action\PlaceholderAction }

#- api_resources.yml

resources:
    AppBundle\Entity\Foo:
        collectionOperations:
            get:
                method: 'GET'
            post:
                method: 'POST'
            domain:
                method: 'GET'

<?php
class FooCollectionDataProvider implements CollectionDataProviderInterface, RestrictedDataProviderInterface {
    public function supports(string $resourceClass, string $operationName = null): bool
    {
        return $resourceClass === Foo::class && $operationName === 'api_foos_by_domain';
    }

   //...
}

services:
    _defaults:
        autowire: true
        public: false

    AppBundle\DataProvider\FooCollectionDataProvider:
        tags:
            - { name: 'api_platform.collection_data_provider', priority: 90}

Example with the EventListener (a lazy way to add data to a given operation):

services:
    FooListener:
        tags:
            - { name: kernel.event_listener, event: kernel.view, method: onKernelView, priority: 20}

Validation has a priority of 64.

<?php
use Symfony\Component\HttpKernel\Event\GetResponseForControllerResultEvent;

final class FooListener
{
    public function __construct(InjectStuffHere $foo)
    {}

    public function onKernelView(GetResponseForControllerResultEvent $event)
    {
        $controllerResult = $event->getControllerResult();

        if (!is_array($controllerResult) || !isset($controllerResult[0])) {
            return;
        }

        if (false === $controllerResult[0] instanceof Component) {
            return;
        }

       // return $controllerResult altered
    }
}

[Simperfit]

@jdeniau is it ok for you ?

[teohhanhui]

I think it's a valid concern. There are different types of validation and not all of them can be fulfilled by API Platform's validation step, and in my project we've had to add a lot of custom authorization/validation logic with listeners.

[jdeniau]

We added a listener too, that can be skipped with a request attribute. As I don't really know how can api-platform address this anyway, this issue is closed for me. Le jeu. 3 mai 2018 à 19:25, Teoh Han Hui <notifications@github.com> a écrit :

…

I think it's a valid concern. There are different types of validation and not all of them can be fulfilled by API Platform's validation step, and in my project we've had to add a lot of custom authorization/validation logic with listeners. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1538 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVWxeJENUzIYsm3t4EZaHwJXc5V47Eqks5tu0t9gaJpZM4Q072a> .

[lyrixx]

I also think this is a valid concern. Let's take a very simple example : I have an entity that I can "pin" and "unpin".
So I write a simple controller for that:

    public function __invoke(Crawl $crawl)
    {
        $errors = $this->validator->validate($crawl);

        if (\count($errors) > 0) {
            throw new ValidationException($errors);
        }

        $crawl->pin();

        return $crawl;
    }

It works but there is 2 drawbacks here

1. I have to manually trigger the validation
2. The validation is triggered twice because APIP also does it after the is returned

---

To me this is not intuitive because in the controller, it's the place we can work. And we expect the data to be valid.

I understand changing the position of the listener would be a huge BC, but I'm sure we can mitigate it easily with an option or something else.

Could we re-open this issue to discuss in depth about it? Thanks

[julienfalque]

Looks similar to #3261.