Skip to content

[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

Merged
merged 6 commits into from
Nov 8, 2020
Merged

[ValidationException] Allow customization of validation error status code #3808

merged 6 commits into from
Nov 8, 2020

Conversation

ahmed-bhs
Copy link
Contributor

@ahmed-bhs ahmed-bhs commented Oct 31, 2020

Q A
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Fixed tickets
License MIT
Doc PR api-platform/docs#1206

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 :

api_platform:
    exception_to_status:
        ApiPlatform\Core\Bridge\Symfony\Validator\Exception\ValidationException: !php/const Symfony\Component\HttpFoundation\Response::HTTP_UNPROCESSABLE_ENTITY

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,

@soyuka soyuka added the Ready label Nov 8, 2020
Copy link
Member

@soyuka soyuka left a 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 ?

@ahmed-bhs
Copy link
Contributor Author

@soyuka rebase is done, but It seems like most of the ci builds are failing after merging #3764 PR!

@soyuka
Copy link
Member

soyuka commented Nov 8, 2020

I'll handle the rest I though I just fixed the missing tests in #3818 :)

@soyuka soyuka merged commit 5b2cfdc into api-platform:master Nov 8, 2020
@soyuka
Copy link
Member

soyuka commented Nov 8, 2020

Thanks @ahmed-bhs !

@silverbackdan
Copy link
Contributor

silverbackdan commented Dec 16, 2020

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?

@bpolaszek
Copy link
Contributor

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 :-)

@odoucet
Copy link
Contributor

odoucet commented Feb 11, 2021

Hello,
I confirm this is a BC, I needed to update all unit tests to match 422 instead of 400.

@ahmed-bhs ahmed-bhs deleted the feature/support-changing-status-code-for-validation-exception branch February 11, 2021 13:43
@ahmed-bhs
Copy link
Contributor Author

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants