Problem Details for machine-readable details of errors in a HTTP response

[maxbeckers]

There is a RFC 7807 for a response structure for error cases. For more details see https://tools.ietf.org/html/rfc7807. For a form validation error it could be like this:

   {
   "type": "https://example.net/validation-error",
   "title": "Your request parameters didn't validate.",
   "invalid-params": [ {
                         "name": "age",
                         "reason": "must be a positive integer"
                       },
                       {
                         "name": "color",
                         "reason": "must be 'green', 'red' or 'blue'"}
                     ]
   }

[GuilhemN]

It does look more suited than our current format indeed but it would force our users to put a lot of energy in the upgrade to the next major release of this bundle for no much gain imo.

We could offer an option to use this rfc for new projects but I wouldn't make it the default because of backward compatibility.

[Tobion]

In Symfony 4.4 there is a new error rendering that is compatible with this RFC. If we want to make the FosRestBundle compatible with SF 4.4 and prevents deprecations, we likely need to switch to that new error rendering as well. So this change will come sooner or later. The question is only how to make the best transition.

[maxbeckers]

I think we can have a new config for this bundle, which is the current error response handling by default but can be set to the rfc response structure. With this solution it could be possible to add custom response structures for use cases with other error response requirements.

[xabbuh]

FOSRestBundle 2.8/3.0 will allow to enable RFC 7807 compatible error responses leveraging the Symfony ErrorHandler component with the flatten_exception_format option:

fos_rest:
       exception:
           flatten_exception_format: 'rfc7807'