[Serializer] Added a ConstraintViolationListNormalizer #22150

Merged
merged 1 commit into from Mar 23, 2018

Conversation

@lyrixx
Member

lyrixx commented Mar 24, 2017

Q A
Branch? master
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets #11309
License MIT
Doc PR -

It seems logical to me that Symfony is able to serialise natively some very common Symfony data structure. (and requested by @nicolas-grekas & @javiereguiluz )

Usage example (from symfony/symfony-demo):

    /**
     * @Route("", name="api_blog_new")
     * @Method("POST")
     * @Security("is_granted('ROLE_ADMIN')")
     */
    public function newAction(Request $request)
    {
        $data = $request->getContent();

        $post = $this->get('serializer')->deserialize($data, Post::class, 'json', ['groups' => ['post_write']]);

        $post->setAuthor($this->getUser());

        $violations = $this->get('validator')->validate($post);

        $post->setSlug($this->get('slugger')->slugify($post->getTitle()));

        if (count($violations) > 0) {
            $repr = $this->get('serializer')->serialize($violations, 'json');

            return JsonResponse::fromJsonString($repr, 400);
        }

        $this->getDoctrine()->getManager()->persist($post);
        $this->getDoctrine()->getManager()->flush();

        $repr = $this->get('serializer')->serialize($post, 'json', ['groups' => ['post_read']]);

        return JsonResponse::fromJsonString($repr);
    }
@@ -1202,6 +1203,13 @@ private function registerSerializerConfiguration(array $config, ContainerBuilder
$definition->addTag('serializer.normalizer', array('priority' => -900));
}
+ if (class_exists('Symfony\Component\Serializer\Normalizer\ConstraintViolationListNormalizer')) {

This comment has been minimized.

@theofidry

theofidry Mar 24, 2017

Contributor

class_exists(ConstraintViolationListNormalize::class)

@theofidry

theofidry Mar 24, 2017

Contributor

class_exists(ConstraintViolationListNormalize::class)

This comment has been minimized.

@lyrixx

lyrixx Mar 24, 2017

Member

No, I want to be consistent with other usage in this file. just above and bellow

@lyrixx

lyrixx Mar 24, 2017

Member

No, I want to be consistent with other usage in this file. just above and bellow

This comment has been minimized.

@ro0NL

ro0NL Mar 24, 2017

Contributor

Had the same issue with https://github.com/symfony/symfony/pull/20567/files#diff-1cf8b3cc93de9c5674101413d27a9bf0R47, at first i thought; lets be consistent.

On 2nd thought i chose to just use ::class notation for new code, as it's the better syntax and exposes class deps (ie. it improves usage tracking, and therefor maintenance). It got merged :))

@ro0NL

ro0NL Mar 24, 2017

Contributor

Had the same issue with https://github.com/symfony/symfony/pull/20567/files#diff-1cf8b3cc93de9c5674101413d27a9bf0R47, at first i thought; lets be consistent.

On 2nd thought i chose to just use ::class notation for new code, as it's the better syntax and exposes class deps (ie. it improves usage tracking, and therefor maintenance). It got merged :))

@javiereguiluz

👍 it looks like a useful feature to me! Thanks @lyrixx.

+
+ return array(
+ 'title' => 'An error occurred',
+ 'detail' => $messages ? implode("\n", $messages) : (string) $violationsList,

This comment has been minimized.

@javiereguiluz

javiereguiluz Mar 24, 2017

Member

I'm not sure about Symfony's policy about this, but do we use PHP_EOL instead of \n?

@javiereguiluz

javiereguiluz Mar 24, 2017

Member

I'm not sure about Symfony's policy about this, but do we use PHP_EOL instead of \n?

This comment has been minimized.

@lyrixx

lyrixx Mar 24, 2017

Member

Updated

@lyrixx

lyrixx Mar 24, 2017

Member

Updated

+ }
+
+ return array(
+ 'title' => 'An error occurred',

This comment has been minimized.

@ro0NL

ro0NL Mar 24, 2017

Contributor

Isnt this format rather opinionated? Do we really need it compared to return $violations;.

Point is; i like to integrate such a normalizer in one of my api response providers, by doing something like;

return new JsonResponse([
  'our_api_format' => [
    'errors' => $normalizer->normalize($violations),
  ],
]);

Any thoughts?

@ro0NL

ro0NL Mar 24, 2017

Contributor

Isnt this format rather opinionated? Do we really need it compared to return $violations;.

Point is; i like to integrate such a normalizer in one of my api response providers, by doing something like;

return new JsonResponse([
  'our_api_format' => [
    'errors' => $normalizer->normalize($violations),
  ],
]);

Any thoughts?

This comment has been minimized.

@lyrixx

lyrixx Mar 24, 2017

Member

You are right. Actually I adapted code from API platform (that's why I kept Kevin as author)
But actually I like this format. But I'm open to suggestions.

@lyrixx

lyrixx Mar 24, 2017

Member

You are right. Actually I adapted code from API platform (that's why I kept Kevin as author)
But actually I like this format. But I'm open to suggestions.

@nicolas-grekas nicolas-grekas added this to the 3.3 milestone Mar 28, 2017

+ * @author Grégoire Pineau <lyrixx@lyrixx.info>
+ * @author Kévin Dunglas <dunglas@gmail.com>
+ */
+class ConstraintViolationListNormalizer implements NormalizerInterface

This comment has been minimized.

@dunglas

dunglas Mar 28, 2017

Member

The description looks not accurate.

@dunglas

dunglas Mar 28, 2017

Member

The description looks not accurate.

This comment has been minimized.

@lyrixx

lyrixx Mar 29, 2017

Member

Fixed.

@lyrixx

lyrixx Mar 29, 2017

Member

Fixed.

@dunglas

This comment has been minimized.

Show comment
Hide comment
@dunglas

dunglas Mar 28, 2017

Member

The original implementation (https://github.com/api-platform/core/blob/master/src/Hydra/Serializer/ConstraintViolationListNormalizer.php) was following the Hydra W3C draft.

WDYT about keeping Hydra support in Symfony?

Member

dunglas commented Mar 28, 2017

The original implementation (https://github.com/api-platform/core/blob/master/src/Hydra/Serializer/ConstraintViolationListNormalizer.php) was following the Hydra W3C draft.

WDYT about keeping Hydra support in Symfony?

@dunglas

This comment has been minimized.

Show comment
Hide comment
@dunglas

dunglas Mar 28, 2017

Member

Another alternative is to implement RFC7807 (supported by API Platform and Zend Apigility): https://github.com/api-platform/core/blob/master/src/Problem/Serializer/ConstraintViolationListNormalizer.php

Member

dunglas commented Mar 28, 2017

Another alternative is to implement RFC7807 (supported by API Platform and Zend Apigility): https://github.com/api-platform/core/blob/master/src/Problem/Serializer/ConstraintViolationListNormalizer.php

@javiereguiluz

This comment has been minimized.

Show comment
Hide comment
@javiereguiluz

javiereguiluz Mar 28, 2017

Member

RFC7807 looks like the ideal solution to create something standard ... but its status is still: "PROPOSED STANDARD". Can we guess the chances of being changed a lot in the future or even rejected?

Member

javiereguiluz commented Mar 28, 2017

RFC7807 looks like the ideal solution to create something standard ... but its status is still: "PROPOSED STANDARD". Can we guess the chances of being changed a lot in the future or even rejected?

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Mar 29, 2017

Member

I implemented RFC7807 (supported by API Platform and Zend Apigility)

Member

lyrixx commented Mar 29, 2017

I implemented RFC7807 (supported by API Platform and Zend Apigility)

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Mar 29, 2017

Member

Can you add a note about the fact that it implements RFC7807 in the phpdocs?

Member

fabpot commented Mar 29, 2017

Can you add a note about the fact that it implements RFC7807 in the phpdocs?

+ foreach ($object as $violation) {
+ $violations[] = array(
+ 'propertyPath' => $violation->getPropertyPath(),
+ 'message' => $violation->getMessage(),

This comment has been minimized.

@stof

stof Mar 30, 2017

Member

I would also add the code ($violation->getCode()) for the machine-readable stable identifier of the violation (the message is not stable as it is translated)

@stof

stof Mar 30, 2017

Member

I would also add the code ($violation->getCode()) for the machine-readable stable identifier of the violation (the message is not stable as it is translated)

This comment has been minimized.

@lyrixx

lyrixx Apr 3, 2017

Member

Good idea.

@lyrixx

lyrixx Apr 3, 2017

Member

Good idea.

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Apr 3, 2017

Member

Comment addressed. PR updated.

Note: I also renamed propertyPath to property_path`.

Member

lyrixx commented Apr 3, 2017

Comment addressed. PR updated.

Note: I also renamed propertyPath to property_path`.

+ return array(
+ 'type' => isset($context['type']) ? $context['type'] : 'https://tools.ietf.org/html/rfc2616#section-10',
+ 'title' => isset($context['title']) ? $context['title'] : 'An error occurred',
+ 'detail' => $messages ? implode("\n", $messages) : (string) $object,

This comment has been minimized.

@ro0NL

ro0NL Apr 3, 2017

Contributor

Not sure we can safely rely on (string) $object as __toString is not part of the interface. Do we really need the fallback?

@ro0NL

ro0NL Apr 3, 2017

Contributor

Not sure we can safely rely on (string) $object as __toString is not part of the interface. Do we really need the fallback?

This comment has been minimized.

@lyrixx

lyrixx Apr 3, 2017

Member

Removed.

@lyrixx

lyrixx Apr 3, 2017

Member

Removed.

@dunglas

This comment has been minimized.

Show comment
Hide comment
@dunglas

dunglas Apr 3, 2017

Member

Note: I also renamed propertyPath to property_path

Why this change? AFAIK, camel case is preferred (for instance, it's what Google and Schema.org use).

Member

dunglas commented Apr 3, 2017

Note: I also renamed propertyPath to property_path

Why this change? AFAIK, camel case is preferred (for instance, it's what Google and Schema.org use).

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Apr 3, 2017

Member

Ah ok. I will revert it so. Usually I prefer Snake Case in my array / API...

Member

lyrixx commented Apr 3, 2017

Ah ok. I will revert it so. Usually I prefer Snake Case in my array / API...

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Apr 3, 2017

Member

Reverted. The PR is now ready.

Member

lyrixx commented Apr 3, 2017

Reverted. The PR is now ready.

@dunglas

dunglas approved these changes Apr 3, 2017

+ );
+ }
+
+ public function supportsNormalization($data, $format = null)

This comment has been minimized.

@dunglas

dunglas Apr 3, 2017

Member

{@inheritdoc} is missing.

@dunglas

dunglas Apr 3, 2017

Member

{@inheritdoc} is missing.

This comment has been minimized.

@lyrixx

lyrixx Apr 3, 2017

Member

Thanks. Fixed

@lyrixx

lyrixx Apr 3, 2017

Member

Thanks. Fixed

@dunglas

This comment has been minimized.

Show comment
Hide comment
@dunglas

dunglas Apr 3, 2017

Member

👍 for me. @teohhanhui would you mind reviewing this PR? I know you studied this RFC.

Member

dunglas commented Apr 3, 2017

👍 for me. @teohhanhui would you mind reviewing this PR? I know you studied this RFC.

@ro0NL

ro0NL approved these changes Apr 3, 2017

@teohhanhui

This comment has been minimized.

Show comment
Hide comment
@teohhanhui

teohhanhui Apr 3, 2017

Contributor

This PR seems to bring over the same mistakes as I've pointed out in api-platform/core#793

Reproducing it here:

The current implementation is not RFC 7807 compliant:

Consumers MUST use the "type" string as the primary identifier for the problem type
(https://tools.ietf.org/html/rfc7807#section-3.1)

A problem's type URI SHOULD resolve to HTML documentation that explains how to resolve the problem.
(https://tools.ietf.org/html/rfc7807#section-4)

But instead we're using a link to the "Status Code Definitions" section of RFC 2616 (deprecated and replaced by RFC 7231).

So I propose we should omit the "type" altogether, which is allowed:

When this member is not present, its value is assumed to be "about:blank".
(https://tools.ietf.org/html/rfc7807#section-3.1)

In which case the spec further states:

When "about:blank" is used, the title SHOULD be the same as the recommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on)
(https://tools.ietf.org/html/rfc7807#section-4.2)

Contributor

teohhanhui commented Apr 3, 2017

This PR seems to bring over the same mistakes as I've pointed out in api-platform/core#793

Reproducing it here:

The current implementation is not RFC 7807 compliant:

Consumers MUST use the "type" string as the primary identifier for the problem type
(https://tools.ietf.org/html/rfc7807#section-3.1)

A problem's type URI SHOULD resolve to HTML documentation that explains how to resolve the problem.
(https://tools.ietf.org/html/rfc7807#section-4)

But instead we're using a link to the "Status Code Definitions" section of RFC 2616 (deprecated and replaced by RFC 7231).

So I propose we should omit the "type" altogether, which is allowed:

When this member is not present, its value is assumed to be "about:blank".
(https://tools.ietf.org/html/rfc7807#section-3.1)

In which case the spec further states:

When "about:blank" is used, the title SHOULD be the same as the recommended HTTP status phrase for that code (e.g., "Not Found" for 404, and so on)
(https://tools.ietf.org/html/rfc7807#section-4.2)

@teohhanhui

This comment has been minimized.

Show comment
Hide comment
@teohhanhui

teohhanhui Apr 3, 2017

Contributor

Since we're normalizing Symfony Validator constraint violations, it'd be perfect if we have specific pages on symfony.com to explain each violation (this would be what we put in the type property of the Problem Details object). We already have a UUID for each violation, so let's make full use of that.

(Echoing @webmozart's original suggestion in #15154)

Contributor

teohhanhui commented Apr 3, 2017

Since we're normalizing Symfony Validator constraint violations, it'd be perfect if we have specific pages on symfony.com to explain each violation (this would be what we put in the type property of the Problem Details object). We already have a UUID for each violation, so let's make full use of that.

(Echoing @webmozart's original suggestion in #15154)

@dunglas

This comment has been minimized.

Show comment
Hide comment
@dunglas

dunglas Sep 26, 2017

Member

Any update about this one?

Member

dunglas commented Sep 26, 2017

Any update about this one?

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Sep 26, 2017

Member

What should I do ?

Member

lyrixx commented Sep 26, 2017

What should I do ?

@dunglas

This comment has been minimized.

Show comment
Hide comment
@dunglas

dunglas Sep 27, 2017

Member

Fixing the comments raised by @teohhanhui

Member

dunglas commented Sep 27, 2017

Fixing the comments raised by @teohhanhui

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Oct 5, 2017

Member

I have rebased this PR and now it's targeting 4.1 (I guess it's too late for 3.4 ?)

I have removed the type attribute of the response.

This normalizer still does not really implement the RFC. It's not really possible. We can not get the HTTP Status code of the response.

So I don't know how to unlock this PR. May be we can simply remove the reference to the RFC, or to explain it does not follow each rules of the RFC.

What do you think ?

Member

lyrixx commented Oct 5, 2017

I have rebased this PR and now it's targeting 4.1 (I guess it's too late for 3.4 ?)

I have removed the type attribute of the response.

This normalizer still does not really implement the RFC. It's not really possible. We can not get the HTTP Status code of the response.

So I don't know how to unlock this PR. May be we can simply remove the reference to the RFC, or to explain it does not follow each rules of the RFC.

What do you think ?

@dunglas

This comment has been minimized.

Show comment
Hide comment
@dunglas

dunglas Oct 5, 2017

Member

The status code can be passed through the context (it can be optional).

Member

dunglas commented Oct 5, 2017

The status code can be passed through the context (it can be optional).

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Oct 5, 2017

Member

The status code can be passed through the context (it can be optional).

But it's not mandatory, and it's boring if you need to pass 4XX each time ... :/

Member

lyrixx commented Oct 5, 2017

The status code can be passed through the context (it can be optional).

But it's not mandatory, and it's boring if you need to pass 4XX each time ... :/

@nicolas-grekas nicolas-grekas modified the milestones: 3.4, 4.1 Oct 8, 2017

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Feb 16, 2018

Member

I have rebased the PR ; it's not ready

Member

lyrixx commented Feb 16, 2018

I have rebased the PR ; it's not ready

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Mar 14, 2018

Member

Ping

Member

lyrixx commented Mar 14, 2018

Ping

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Mar 22, 2018

Member

@lyrixx "it's not ready" -> I suppose you meant "it's now ready", right?

Member

fabpot commented Mar 22, 2018

@lyrixx "it's not ready" -> I suppose you meant "it's now ready", right?

+ of objects that needs data insertion in constructor
+ * added an optional `default_constructor_arguments` option of context to specify a default data in
+ case the object is not initializable by its constructor because of data missing
+ * added optional `bool $escapeFormulas = false` argument to `CsvEncoder::__construct`

This comment has been minimized.

@fabpot

fabpot Mar 22, 2018

Member

Looks like you haven't added anything here.

@fabpot

fabpot Mar 22, 2018

Member

Looks like you haven't added anything here.

+use Symfony\Component\Validator\ConstraintViolationListInterface;
+
+/**
+ * A normalizer that normalize a ConstraintViolationListInterface instance.

This comment has been minimized.

@fabpot

fabpot Mar 22, 2018

Member

normalizes

@fabpot

fabpot Mar 22, 2018

Member

normalizes

+/**
+ * A normalizer that normalize a ConstraintViolationListInterface instance.
+ *
+ * This Normalizer implements RFC7807 {@link https://tools.ietf.org/html/rfc7807}.

This comment has been minimized.

@fabpot

fabpot Mar 22, 2018

Member

If we're not fully compliant, it should be added here.

@fabpot

fabpot Mar 22, 2018

Member

If we're not fully compliant, it should be added here.

@lyrixx

This comment has been minimized.

Show comment
Hide comment
@lyrixx

lyrixx Mar 22, 2018

Member

@lyrixx "it's not ready" -> I suppose you meant "it's now ready", right?

Oups, You are right.


I have addressed your comment. It should be OK now

Member

lyrixx commented Mar 22, 2018

@lyrixx "it's not ready" -> I suppose you meant "it's now ready", right?

Oups, You are right.


I have addressed your comment. It should be OK now

@fabpot

fabpot approved these changes Mar 22, 2018

minor comment

+/**
+ * A normalizer that normalizes a ConstraintViolationListInterface instance.
+ *
+ * This Normalizer implements partially RFC7807 {@link https://tools.ietf.org/html/rfc7807}.

This comment has been minimized.

@fabpot

fabpot Mar 22, 2018

Member

I would say implements RFC7807 partially.

But can we be a bit more precise? Can we list what we do not support or how we diverge from the RFC? I think that would help our users.

@fabpot

fabpot Mar 22, 2018

Member

I would say implements RFC7807 partially.

But can we be a bit more precise? Can we list what we do not support or how we diverge from the RFC? I think that would help our users.

This comment has been minimized.

@lyrixx

lyrixx Mar 22, 2018

Member

Actually I re-read the RFC and came up to the same conclusion as @teohhanhui's comment.

We are allowed to omit the type property.

That's why I removed the "partially" because the normalizer do implement the RFC.

@lyrixx

lyrixx Mar 22, 2018

Member

Actually I re-read the RFC and came up to the same conclusion as @teohhanhui's comment.

We are allowed to omit the type property.

That's why I removed the "partially" because the normalizer do implement the RFC.

@fabpot

This comment has been minimized.

Show comment
Hide comment
@fabpot

fabpot Mar 23, 2018

Member

Thank you @lyrixx.

Member

fabpot commented Mar 23, 2018

Thank you @lyrixx.

@fabpot fabpot merged commit 2a35d09 into symfony:master Mar 23, 2018

2 of 3 checks passed

continuous-integration/appveyor/pr AppVeyor build failed
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
fabbot.io Your code looks good.
Details

fabpot added a commit that referenced this pull request Mar 23, 2018

feature #22150 [Serializer] Added a ConstraintViolationListNormalizer…
… (lyrixx)

This PR was merged into the 4.1-dev branch.

Discussion
----------

[Serializer] Added a ConstraintViolationListNormalizer

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #11309
| License       | MIT
| Doc PR        | -

---

It seems logical to me that Symfony is able to serialise natively some very common Symfony data structure. (and requested by @nicolas-grekas & @javiereguiluz )

Usage example (from symfony/symfony-demo):

```php
    /**
     * @route("", name="api_blog_new")
     * @method("POST")
     * @Security("is_granted('ROLE_ADMIN')")
     */
    public function newAction(Request $request)
    {
        $data = $request->getContent();

        $post = $this->get('serializer')->deserialize($data, Post::class, 'json', ['groups' => ['post_write']]);

        $post->setAuthor($this->getUser());

        $violations = $this->get('validator')->validate($post);

        $post->setSlug($this->get('slugger')->slugify($post->getTitle()));

        if (count($violations) > 0) {
            $repr = $this->get('serializer')->serialize($violations, 'json');

            return JsonResponse::fromJsonString($repr, 400);
        }

        $this->getDoctrine()->getManager()->persist($post);
        $this->getDoctrine()->getManager()->flush();

        $repr = $this->get('serializer')->serialize($post, 'json', ['groups' => ['post_read']]);

        return JsonResponse::fromJsonString($repr);
    }
```

Commits
-------

2a35d09 [Serializer] Added a ConstraintViolationListNormalizer

@javiereguiluz javiereguiluz referenced this pull request in symfony/symfony-docs Mar 23, 2018

Closed

[Serializer] Added a ConstraintViolationListNormalizer #9480

@lyrixx lyrixx deleted the lyrixx:serializer-ConstraintViolationListNormalizer branch May 3, 2018

@fabpot fabpot referenced this pull request May 7, 2018

Merged

Release v4.1.0-BETA1 #27181

+ ));
+
+ $expected = array(
+ 'title' => 'An error occurred',

This comment has been minimized.

@teohhanhui

teohhanhui May 16, 2018

Contributor

RFC 7807 is unambiguous on this point:

3.1. Members of a Problem Details Object

A problem details object can have the following members:

  • "type" (string) - ... When
    this member is not present, its value is assumed to be
    "about:blank".

4.2. Predefined Problem Types

This specification reserves the use of one URI as a problem type:

The "about:blank" URI [RFC6694], when used as a problem type,
indicates that the problem has no additional semantics beyond that of
the HTTP status code.

When "about:blank" is used, the title SHOULD be the same as the
recommended HTTP status phrase for that code (e.g., "Not Found" for
404, and so on), although it MAY be localized to suit client
preferences (expressed with the Accept-Language request header).

Please note that according to how the "type" member is defined
(Section 3.1), the "about:blank" URI is the default value for that
member. Consequently, any problem details object not carrying an
explicit "type" member implicitly uses this URI.

Perhaps:

{
  "type": "/validation-error",
  "title": "Validation failed",
  ...
}
@teohhanhui

teohhanhui May 16, 2018

Contributor

RFC 7807 is unambiguous on this point:

3.1. Members of a Problem Details Object

A problem details object can have the following members:

  • "type" (string) - ... When
    this member is not present, its value is assumed to be
    "about:blank".

4.2. Predefined Problem Types

This specification reserves the use of one URI as a problem type:

The "about:blank" URI [RFC6694], when used as a problem type,
indicates that the problem has no additional semantics beyond that of
the HTTP status code.

When "about:blank" is used, the title SHOULD be the same as the
recommended HTTP status phrase for that code (e.g., "Not Found" for
404, and so on), although it MAY be localized to suit client
preferences (expressed with the Accept-Language request header).

Please note that according to how the "type" member is defined
(Section 3.1), the "about:blank" URI is the default value for that
member. Consequently, any problem details object not carrying an
explicit "type" member implicitly uses this URI.

Perhaps:

{
  "type": "/validation-error",
  "title": "Validation failed",
  ...
}

fabpot added a commit that referenced this pull request May 21, 2018

bug #27292 [Serializer] Fix and improve constraintViolationListNormal…
…izer's RFC7807 compliance (dunglas)

This PR was squashed before being merged into the 4.1 branch (closes #27292).

Discussion
----------

[Serializer] Fix and improve constraintViolationListNormalizer's RFC7807 compliance

| Q             | A
| ------------- | ---
| Branch?       | 4.1
| Bug fix?      | yes
| New feature?  | no <!-- don't forget to update src/**/CHANGELOG.md files -->
| BC breaks?    | no     <!-- see https://symfony.com/bc -->
| Deprecations? | yes| Tests pass?   | yes    <!-- please add some, will be required by reviewers -->
| Fixed tickets | #22150 (comment)
| License       | MIT
| Doc PR        | todo

This PR fixes and improves [RFC 7807](https://tools.ietf.org/html/rfc7807#section-3.2) compliance of `ConstraintViolationListNormalizer` (introduced in 4.1):

* As recommended, use a specific namespace for Symfony validation error (`http://symfony.com/doc/current/validation.html`, because it already exists and gives information about the error.
* Allow to set all properties defined in the RFC using the serialization context
* Remove the `detail` key if no detail is provided (according to the spec)
* Change the Symfony specific extension to use the same terminology than the RFC itself (type and title)
* Use the proper `urn:uuid` scheme (RFC 4122) for the UUID code (more standard, and improve hypermedia capabilities).

ping @teohhanhui

Commits
-------

3c789c6 [Serializer] Fix and improve constraintViolationListNormalizer's RFC7807 compliance

@lyrixx lyrixx referenced this pull request in symfony/symfony-docs Jul 3, 2018

Open

[Validator] Document each constraint code #10001

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment