You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Django Ninja has default exception handlers for cases like authentication or validation errors. It's lovely how straightforward it is to expand on these for custom use cases.
What is the recommended approach to exposing the format of these generic error responses to the generated OpenAPI specification?
Ideally, this can be done at the root API level or per router. For example in a similar fashion how this can be accomplished using drf-spectacular + drf-standardized-errors when using drf.
A typical example would be that for ValidationErrors the 422 error and the error schema are exposed for any endpoint that uses an input Schema. Adding this manually to each relevant API as @router.post('/some-url', response={201: MyObjectOut, 422: MyCustomValidationError}) feels error prone.
The text was updated successfully, but these errors were encountered:
Django Ninja has default exception handlers for cases like authentication or validation errors. It's lovely how straightforward it is to expand on these for custom use cases.
What is the recommended approach to exposing the format of these generic error responses to the generated OpenAPI specification?
Ideally, this can be done at the root API level or per router. For example in a similar fashion how this can be accomplished using
drf-spectacular
+drf-standardized-errors
when usingdrf
.A typical example would be that for
ValidationErrors
the 422 error and the error schema are exposed for any endpoint that uses an input Schema. Adding this manually to each relevant API as@router.post('/some-url', response={201: MyObjectOut, 422: MyCustomValidationError})
feels error prone.The text was updated successfully, but these errors were encountered: