Machine readable errors

[agowa]

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

Invoke the rest api with wrong parameters or attributes.

Expected behavior

RFC7807 compliant error reporting.

E.g. something like:

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: en

{
"type": "https://example.net/validation-error",
"title": "Your request parameters didn't validate.",
"invalid_params": [ {
                      "name": "age",
                      "reason": "must be a positive integer"
                    },
                    {
                      "name": "color",
                      "reason": "must be 'green', 'red' or 'blue'"}
                  ]
}

Actual behavior

Shows error messages that are hard to deal within scripts. And are only human readable.

An example for how the problem looks like in a real live scenario is available over at netbox-community/netbox#5119. They sent me here, as the issue is something the framework does and not something they could implement/fix.

This issue also relates to:

• ValidationError doesn't preserve JSON field's types #7532
• Suggestion: Multiple response support in Schema Generation. #7413
• ListField validation errors are inconsistent with ListSerializer #7279

[xordoquy]

the issue is something the framework does and not something they could implement/fix.

It would be more correct to say it is something they don't want to fix.
You can change the default error representation by overriding the default error handler.
Please note that RFC7807 is much younger than DRF and it is unlikely that we change the default error handler.
We probably could add another error handler that would implement that RFC though and some 3rd party may already implement it - haven't looked.
Meanwhile, as it is possible to override the default handler to implement RFC7807, I'm closing this issue.

[agowa]

Thanks for the clarification.

And for reference, there is a 3rd party library called drf-problems:
https://shivanshs9.me/medium/drf-problems-21f7bb4d4675
https://pypi.org/project/drf-problems/

[ChrisCrossCrash]

@xordoquy Just so you know, I wanted the exact same thing as you. drf-problems works great, but it doesn't put the invalid parameters into an invalid-params property like the example given in the RFC7807 specification. I made a fork that does exactly that if you are interested.