There was a typo under ## What REST framework doesn't provide.
Original: What REST framework doesn't do is give you is machine readable hypermedia formats such as [HAL][hal],
Fixed: What REST framework doesn't do is give you machine readable hypermedia formats such as [HAL][hal],
This change addresses use cases that require more information about reported
validation errors. Currently for each error that REST Framework reports users
get only that error's message string. The message can be translated so there's
no good way to recognize programmatically what sort of an error it is.
When building an API that is supposed to return error codes, I've found it very
limiting. For example, I was supposed to differentiate between missing fields
and invalid arguments. The only way to do it right now was to monkey-patch all
hard coded error messages and prefix them with an error code, then write a custom
exception handler that unpacked those error codes and acted accordingly.
Alternatively, I could write my own set of Field and Validator classes that
would throw different exception. In either case, it felt like this is something
that has to be addressed within the REST Framework itself.
This commit introduces proper error codes handling to the Validation Error, and
a customizable error builder that let's users pick how they want to represent
their errors.
ValidationError can hold a single error itself (text), a list of those, or a
dictionary mapping errors to fields. Error code is only meaningful for a single
error, and I've added assertions to check for proper usage.
To help with my development, I've added a setting that makes error code a
mandatory argument. Thanks to this, I was able to correct all uses of
ValidationError across the code.
Information about errors was originally available via ValidationError.detail,
and format of these data must not change, because users can have custom
exception handlers that rely on it. So to maintain backward compatibility, I've
added customizable error builder. By default, it discards the error code.
Users are supposed to change that error builder in settings if they want to use
error codes in their exception handler. If they do so, the structure of
ValidationError.detail does not change, but in the leafs they'll find results
from their error builder.
