search

ghazi-git / drf-standardized-errors

Standardize your DRF API error responses
https://drf-standardized-errors.readthedocs.io/en/latest/
MIT License
249 stars 14 forks source link

Proposal for a standardized format (application/problem+json) #56

Open gabn88 opened 8 months ago

gabn88 commented 8 months ago

I like this package, because I know what a hassle the exception_handler can be. I was wondering if you would consider moving to a more standardized format, like for example problem+json? This can of course be done as a setting.

Explanation problem+json: https://lakitna.medium.com/understanding-problem-json-adf68e5cf1f8. Specs: https://datatracker.ietf.org/doc/html/rfc7807

ghazi-git commented 8 months ago

Honestly, the main reason for making the handler easy to customize is allowing everyone to change the format to suit their requirements. Out of the box, I tried to have the default format support multiple errors (for validation errors) and make it easy to document with OpenAPI (always have the same format: errors is a list even if there is one error).

I gave the article a quick read and I don't think we should move to it as the default: it does not promote multiple errors by default, error codes will require a custom member and seems to promote more customization to the format depending on the error as opposed to keeping the format the same always. Still, I like your idea about making it a setting. So, what do you think about contributing this a custom ExceptionFormatter? it will serve as a good example of how to customize the error response and others can use it easily by updating the EXCEPTION_FORMATTER_CLASS setting. Also, it would be great if you can work on documenting it with drf-spectacular. Here's a sample implementation that I saw a while ago for the same RFC that explains what I'm suggesting.