The $violations variable contains a ConstraintViolationList object and
it's common to transform it into a list of errors and serialize the list to
include it in a JSON response. That's why in Symfony 4.1 we've added a
ConstraintViolationListNormalizer which does that for you automatically.
The normalizer follows the RFC 7807 specification to generate the list of
errors.

If the constructor of a class defines arguments, as usually happens when using
Value Objects, the serializer won't be able to create the object. In Symfony 4.1
we've introduced a new default_constructor_arguments context option to
solve this problem.

In the following example, both foo and bar are required constructor
arguments but only foo is provided. The value of bar is taken from the
default_constructor_arguments option:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

useSymfony\Component\Serializer\Serializer;useSymfony\Component\Serializer\Normalizer\ObjectNormalizer;classMyObj{private$foo;private$bar;publicfunction__construct($foo,$bar){$this->foo=$foo;$this->bar=$bar;}}$normalizer=newObjectNormalizer($classMetadataFactory);$serializer=newSerializer(array($normalizer));// this is equivalent to $data = new MyObj('Hello', '');$data=$serializer->denormalize(['foo'=>'Hello'],'MyObj',['default_constructor_arguments'=>['MyObj'=>['foo'=>'','bar'=>''],]]);

Sometimes, instead of just stopping the serialization process when the
configured max depth is reached, it's better to let the developer handle this
situation to return something (e.g. the identifier of the entity).

In Symfony 4.1 you can solve this problem defining a custom handler with the new
setMaxDepthHandler() method: