-
Notifications
You must be signed in to change notification settings - Fork 548
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
Error structuring according to RFC7807 #133
Comments
Hello @duebbert 👋 We haven't specifically used RFC7807, but it seems quite reasonable 👍 I'll add a mention to it in this particular section - https://github.com/HackSoftware/Django-Styleguide#errors--exception-handling Thanks for the issue 🙌 |
Added a mention here - 231773a Cheers! |
Closing for now. If you want to add something else, feel free to reopen 🙌 |
Came across this which might be useful too, although not RFC7807: https://github.com/ghazi-git/drf-standardized-errors |
Have you considered RFC7807 (https://datatracker.ietf.org/doc/html/rfc7807) as a way of structuring errors? I haven't seen it much in the wild but I am always in favour of using standards where possible. Just wondering if you are aware of it and if so what arguments were against using it. Thanks!
Some projects that implemented it:
https://github.com/vapor-ware/fastapi-rfc7807
https://github.com/cbornet/python-httpproblem
https://github.com/dave-shawley/tornado-problem-details
The text was updated successfully, but these errors were encountered: