I do some validation inside of entity validators that isn't possible in field validators, such as comparing field values against one another or checking business logic to determine if the entity is a duplicate (not duplicate UUID, but effectively duplicate content.)
In all cases, if validation fails you get a 422 Unprocessable Entity status code back. This is generally great.
Except if I need to differentiate between invalid fields (the general use case) and the duplicate content case.
I've whipped up the attached MR to very conservatively let violations determine the HTTP status code. If all the violations set a code, and it is the same for all, then use that. Otherwise, default to the current behavior.
This would make json:api a more fluent HTTP API, but totally at the discretion of the developer.
If this looks like it will actually go into core/be entertained, write tests.
Potential for changed HTTP status code.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | interdiff_2-4.txt | 957 bytes | ranjith_kumar_k_u |
| #4 | 3280019-4.patch | 2.81 KB | ranjith_kumar_k_u |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
bradjones1It's worth noting that you have to go out of your way to generate a violation with a code. I'm not aware of any such instances in core.
Comment #4
ranjith_kumar_k_u commentedComment #6
bradjones1Thanks for the reroll, it would be nice to stick to MR though since that's what the issue started with.
Test failures seem easy enough to fix.
Comment #7
bradjones1Soooo, Symfony's core validators set codes to basically an Enum, represented by a UUID. See CountValidator.
I added an is_numeric() to this, but it's still not the "right" solution. It would be nice to still do the underlying goal - allow validation errors to bubble up a status code/have that status inferred somehow, but this would need more thought as to specific implementation.