RequestHandler has its own error handling rather than leaving it to KernelEvents::EXCEPTION event subscribers

This means we leave it to KernelEvents::EXCEPTION event subscribers to generate the appropriate response, rather than duplicating it in RequestHandler in an inconsistent way.

So there are two cases in Drupal core where we assert this inconsistent error response body is returned. Simple enough to fix.

Basically, yes. But by just rethrowing the exception, the system does that for us. As the patch in #2 shows, and as the IS describes.

This should wait for #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method to land, because we'll need to update test coverage there.

#2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method landed!

And, done. Updating the test coverage introduced by #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method.

Moving to 8.3.x-dev, because fixing this might cause disruption in 8.2.x.

The failures in #9 are related to #2813755: JSON responses encoded inconsistently: make them all RFC4627-compliant, possibly also to #2805281: ?_format=hal_json error responses are application/json, yet should be application/hal+json. Postponing.

Yay, #2813755: JSON responses encoded inconsistently: make them all RFC4627-compliant landed!

But… with the additional knowledge I have now, I know for certain the failures are definitely blocked on #2805281: ?_format=hal_json error responses are application/json, yet should be application/hal+json (which is in turn blocked on #2739617: Make it easier to write on4xx() exception subscribers), not on #2813755: JSON responses encoded inconsistently: make them all RFC4627-compliant.

#2739617: Make it easier to write on4xx() exception subscribers landed, #2805281: ?_format=hal_json error responses are application/json, yet should be application/hal+json is now up for review. The PP-1 is correct, it should've been PP-2.

#2805281: ?_format=hal_json error responses are application/json, yet should be application/hal+json was committed, this is now unblocked!

Rebased #9. Straight reroll!

The patch in #9 forgot to change a few lines in HalEntityNormalizationTrait, lines that actually even had explicit todo's pointing to this issue!

CI error at 13 Jan 2017 at 20:26 CET. Now green again.

This is blocking #2827084: EntityNormalizer::denormalize should not throw UnexpectedValueException, but \Symfony\Component\HttpKernel\Exception\UnprocessableEntityHttpException, so we get a 422 response instead of 400. This has been RTBC for almost two weeks now.

How is the IS not honest? It says 99% of REST error responses have this normalization:, which is true.

Any actual application running into 400 responses and asserting/parsing them is broken. The errors that you can conceivably run into are 403 or 404 error responses. And those are already using this format:

    // DX: 403 when unauthorized.
    $response = $this->request('GET', $url, $request_options);
    // @todo Update the message in https://www.drupal.org/node/2808233.
    $this->assertResourceErrorResponse(403, '', $response);

…

  protected function assertResourceErrorResponse($expected_status_code, $expected_message, ResponseInterface $response) {
    $expected_body = $this->serializer->encode(['message' => $expected_message], static::$format);
    $this->assertResourceResponse($expected_status_code, $expected_body, $response);
  }

Also note that it's only for some 400 responses, as this existing code in HEAD proves:

    // DX: 400 when no request body.
    $response = $this->request('POST', $url, $request_options);
    $this->assertResourceErrorResponse(400, 'No entity content received.', $response);

But, sure, I've added an explicit mention of the edge case that is now behaving consistently to the API changes section. "Dishonest" is a pretty strong word to use for this simple oversight IMHO.

CR created: https://www.drupal.org/node/2846775.

No worries. I'd expect inaccurate to be used for that.

Also, yay, #2827084: EntityNormalizer::denormalize should not throw UnexpectedValueException, but \Symfony\Component\HttpKernel\Exception\UnprocessableEntityHttpException, so we get a 422 response instead of 400 is now unblocked :)