-
-
Notifications
You must be signed in to change notification settings - Fork 918
[ValidationException] Allow customization of validation error status code #3808
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ValidationException] Allow customization of validation error status code #3808
Conversation
src/Bridge/Symfony/Validator/EventListener/ValidationExceptionListener.php
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 for this, can you rebase ?
I'll handle the rest I though I just fixed the missing tests in #3818 :) |
Thanks @ahmed-bhs ! |
Quick question: Should this not have been a BC break? People expecting 400 responses now get 422 on validation errors - may be worth marking as BC in the changelog? |
It does, so it should :-) |
Hello, |
@odoucet you can keep the old http code if you dont want to update your unit tests, all you need is to update the exception status code: api_platform:
exception_to_status:
ApiPlatform\Core\Bridge\Symfony\Validator\Exception\ValidationException: !php/const Symfony\Component\HttpFoundation\Response::HTTP_BAD_REQUEST |
In general, I think it's a good practice to use 400 Bad Request http status code when the request body is malformed (i.e. incorrect syntax in the payload or invalid parameters in the URL) and use 422 Unprocessable Entity when the query is semantically incorrect.
According to the RFC https://tools.ietf.org/html/rfc4918#section-11.2 the code 422 seems to me to be much more appropriate and specific in a case of data validation failure.
Cause the server understands the content type of the request entity and the syntax of the request entity is correct but was unable to process the data because its semantically erroneous.
The idea, is to give the hand to configure the status code for the ValidationException under
exception_to_status
section, just like this :Any way, just let me know if this requires to add some unit tests or some documentation, (if it'is an interesting idea).
Best regards,