Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gabn88 opened this issue Jan 3, 2024 · 1 comment
Open

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

gabn88 opened this issue Jan 3, 2024 · 1 comment

Comments

@gabn88
Copy link

gabn88 commented Jan 3, 2024

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants