Open podliashanyk opened 3 years ago
Example 1 and 4 are of the same type: the errors are validation errors for a specific field in the previously posted data. If the same field names are used in the frontend, this makes it possible to connect a specific validation error to a specific field.
Example 3 is default for all 404 replies, so you can safely take whatever text is pointed to by the "detail"-key.
Example 2 is a bit of a mystery, will need research.
There's at least one type missing: you can get a key "non-field-errors" or something like that that is a validation error if there is a relationship between multiple fields. for instance: if you choose X for field A you may not fill anything into field B. This error might also be used for database problems like integrity errors IIRC (integrity errors: most likely caused by multiple fields (columns) being UNIQUE as a set together, which cannot be caught until saving to the database since the values are checked against all existing values of the same type at that point.)
Turns out changing how this works is tricky because as is, ValidationErrors are raised more places than just the validation methods. We'd probably need to clean that up first.
However, taking into account the status code in addition to the json-blob should help matters. Validation-errors should only happen with a 400-status code, and should always have a key-value structure.
How to write your own exception handler, to control the format of the error-jsonblob.
https://rednafi.github.io/reflections/uniform-error-response-in-django-rest-framework.html
Plenty of existing libraries, like this one:
https://github.com/ghazi-git/drf-standardized-errors
drf-problems supports https://www.rfc-editor.org/rfc/rfc7807
Once again, highlighting https://www.rfc-editor.org/rfc/rfc7807
Example:
{
"status": 400,
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/msgs/abc",
"balance": 30,
"accounts": ["/account/12345",
"/account/67890"]
}
"status", "type", "title", "detail" and "instance" are described in RFC 7807, but as you can see other fields may be added, in this case "balance" and "accounts". The latter two may to be described in the page linked to by "type".
Actual behaviour Different endpoints return error cause in different formats.
Example 1:
Example 2:
Example3:
Example4:
Wanted behaviour Uniform error format, for example:
{ "error_message": "Error cause(s) message" }