feat: add payload controller value resolver

[julienfalque]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tickets	-
License	-
Doc PR	-

When creating a custom controller, the argument which is passed the deserialized payload of the request must be named $data. This can be very frustrating, especially when you don't know this requirement and you don't understand why your controller is not working properly.

This PR introduces a controller value resolver that allows to use any argument name, as long as its type declaration matches the resource class.

[dunglas]

I like it!

[ro0NL]

from #3268 , we do

<?php

use ApiPlatform\Core\Validator\ValidatorInterface;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter;
use Sensio\Bundle\FrameworkExtraBundle\Request\ParamConverter\ParamConverterInterface;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Serializer\SerializerInterface;

class ApiInputConverter implements ParamConverterInterface
{
    private $serializer;
    private $validator;

    public function __construct(SerializerInterface $serializer, ValidatorInterface $validator)
    {
        $this->serializer = $serializer;
        $this->validator = $validator;
    }

    public function apply(Request $request, ParamConverter $configuration)
    {
        $attribute = $configuration->getName();

        if ($request->attributes->has($attribute)) {
            return false;
        }

        $input = $this->serializer->deserialize($request->getContent(), $configuration->getClass(), $request->getRequestFormat());

        $this->validator->validate($input);

        $request->attributes->set($attribute, $input);

        return true;
    }

    public function supports(ParamConverter $configuration)
    {
        $options = $configuration->getOptions();

        if ($options['api_input_dto'] ?? false) {
            if (null === $configuration->getClass()) {
                throw new \LogicException('Parameter "'.$configuration->getName().'" must have a class type hint set to deserialize.');
            }

            return true;
        }

        return false;
    }
}

[dunglas]

Do we really need the dependency to SensioExtraFramework? Symfony has some native Param Converter without this dependency for instance.

[ro0NL]

AFAIK it's simply matter of setting a request attribute with deserialized/validated payload. Then we can map it to controller arguments, if needed.

To use different attributes names, i think implementing ArgumentValueResolverInterface will do indeed 👍

[julienfalque]

Right, I forgot about ArgumentValueResolverInterface, I'll rework my PR.

[julienfalque]

PR reworked.

I'd like to add some functional tests. Does it make sense to use Behat for that? I mean: what this PR introduces is more of a technical improvement than a real user feature.

[julienfalque]

Added some integration tests.

[dunglas]

Why do you use the context builder? The current class should be available directly in the attributes.

[julienfalque]

Mmh indeed, resource_class is available in $attributes directly, but I'm not sure about input: the context builder seems to have some custom logic to retrieve it from operation configuration.

[alanpoulain]

Shouldn't we add the integration tests in another file? If possible we prefer to use Behat for this kind of tests too (but maybe it would be harder to test it and these tests seem OK to maintain).

[julienfalque]

If possible we prefer to use Behat

I think it would be much harder to have reliable Behat tests and would require more work to write and maintain. Not worth it IMO.

Shouldn't we add the integration tests in another file

IMO it's fine to keep it here: all tests in this file cover the same subject. But if you prefer, I can extract it to it own file.

[alanpoulain]

@julienfalque LGTM. Could you provide a documentation?

[alanpoulain]

Thank you @julienfalque.

[julienfalque]

Thank you @alanpoulain @dunglas. Sorry I didn't update the documentation, I totally forgot about your request.