exceptions.py
Exceptions… allow error handling to be organized cleanly in a central or high-level place within the program structure.
— Doug Hellmann, Python Exception Handling Techniques
Exception handling in REST framework views
REST framework’s views handle various exceptions, and deal with returning appropriate error responses.
The handled exceptions are:
- Subclasses of
APIException
raised inside REST framework. - Django’s
Http404
exception. - Django’s
PermissionDenied
exception.
In each case, REST framework will return a response with an appropriate status code and content-type. The body of the response will include any additional details regarding the nature of the error.
Most error responses will include a key detail
in the body of the response.
For example, the following request:
DELETE http://api.example.com/foo/bar HTTP/1.1
Accept: application/json
Might receive an error response indicating that the DELETE
method is not allowed on that resource:
HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 42
{"detail": "Method 'DELETE' not allowed."}
Validation errors are handled slightly differently, and will include the field names as the keys in the response. If the validation error was not specific to a particular field then it will use the «non_field_errors» key, or whatever string value has been set for the NON_FIELD_ERRORS_KEY
setting.
An example validation error might look like this:
HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 94
{"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}
Custom exception handling
You can implement custom exception handling by creating a handler function that converts exceptions raised in your API views into response objects. This allows you to control the style of error responses used by your API.
The function must take a pair of arguments, the first is the exception to be handled, and the second is a dictionary containing any extra context such as the view currently being handled. The exception handler function should either return a Response
object, or return None
if the exception cannot be handled. If the handler returns None
then the exception will be re-raised and Django will return a standard HTTP 500 ‘server error’ response.
For example, you might want to ensure that all error responses include the HTTP status code in the body of the response, like so:
HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 62
{"status_code": 405, "detail": "Method 'DELETE' not allowed."}
In order to alter the style of the response, you could write the following custom exception handler:
from rest_framework.views import exception_handler
def custom_exception_handler(exc, context):
# Call REST framework's default exception handler first,
# to get the standard error response.
response = exception_handler(exc, context)
# Now add the HTTP status code to the response.
if response is not None:
response.data['status_code'] = response.status_code
return response
The context argument is not used by the default handler, but can be useful if the exception handler needs further information such as the view currently being handled, which can be accessed as context['view']
.
The exception handler must also be configured in your settings, using the EXCEPTION_HANDLER
setting key. For example:
REST_FRAMEWORK = {
'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler'
}
If not specified, the 'EXCEPTION_HANDLER'
setting defaults to the standard exception handler provided by REST framework:
REST_FRAMEWORK = {
'EXCEPTION_HANDLER': 'rest_framework.views.exception_handler'
}
Note that the exception handler will only be called for responses generated by raised exceptions. It will not be used for any responses returned directly by the view, such as the HTTP_400_BAD_REQUEST
responses that are returned by the generic views when serializer validation fails.
API Reference
APIException
Signature: APIException()
The base class for all exceptions raised inside an APIView
class or @api_view
.
To provide a custom exception, subclass APIException
and set the .status_code
, .default_detail
, and default_code
attributes on the class.
For example, if your API relies on a third party service that may sometimes be unreachable, you might want to implement an exception for the «503 Service Unavailable» HTTP response code. You could do this like so:
from rest_framework.exceptions import APIException
class ServiceUnavailable(APIException):
status_code = 503
default_detail = 'Service temporarily unavailable, try again later.'
default_code = 'service_unavailable'
Inspecting API exceptions
There are a number of different properties available for inspecting the status
of an API exception. You can use these to build custom exception handling
for your project.
The available attributes and methods are:
.detail
— Return the textual description of the error..get_codes()
— Return the code identifier of the error..get_full_details()
— Return both the textual description and the code identifier.
In most cases the error detail will be a simple item:
>>> print(exc.detail)
You do not have permission to perform this action.
>>> print(exc.get_codes())
permission_denied
>>> print(exc.get_full_details())
{'message':'You do not have permission to perform this action.','code':'permission_denied'}
In the case of validation errors the error detail will be either a list or
dictionary of items:
>>> print(exc.detail)
{"name":"This field is required.","age":"A valid integer is required."}
>>> print(exc.get_codes())
{"name":"required","age":"invalid"}
>>> print(exc.get_full_details())
{"name":{"message":"This field is required.","code":"required"},"age":{"message":"A valid integer is required.","code":"invalid"}}
ParseError
Signature: ParseError(detail=None, code=None)
Raised if the request contains malformed data when accessing request.data
.
By default this exception results in a response with the HTTP status code «400 Bad Request».
AuthenticationFailed
Signature: AuthenticationFailed(detail=None, code=None)
Raised when an incoming request includes incorrect authentication.
By default this exception results in a response with the HTTP status code «401 Unauthenticated», but it may also result in a «403 Forbidden» response, depending on the authentication scheme in use. See the authentication documentation for more details.
NotAuthenticated
Signature: NotAuthenticated(detail=None, code=None)
Raised when an unauthenticated request fails the permission checks.
By default this exception results in a response with the HTTP status code «401 Unauthenticated», but it may also result in a «403 Forbidden» response, depending on the authentication scheme in use. See the authentication documentation for more details.
PermissionDenied
Signature: PermissionDenied(detail=None, code=None)
Raised when an authenticated request fails the permission checks.
By default this exception results in a response with the HTTP status code «403 Forbidden».
NotFound
Signature: NotFound(detail=None, code=None)
Raised when a resource does not exists at the given URL. This exception is equivalent to the standard Http404
Django exception.
By default this exception results in a response with the HTTP status code «404 Not Found».
MethodNotAllowed
Signature: MethodNotAllowed(method, detail=None, code=None)
Raised when an incoming request occurs that does not map to a handler method on the view.
By default this exception results in a response with the HTTP status code «405 Method Not Allowed».
NotAcceptable
Signature: NotAcceptable(detail=None, code=None)
Raised when an incoming request occurs with an Accept
header that cannot be satisfied by any of the available renderers.
By default this exception results in a response with the HTTP status code «406 Not Acceptable».
Signature: UnsupportedMediaType(media_type, detail=None, code=None)
Raised if there are no parsers that can handle the content type of the request data when accessing request.data
.
By default this exception results in a response with the HTTP status code «415 Unsupported Media Type».
Throttled
Signature: Throttled(wait=None, detail=None, code=None)
Raised when an incoming request fails the throttling checks.
By default this exception results in a response with the HTTP status code «429 Too Many Requests».
ValidationError
Signature: ValidationError(detail, code=None)
The ValidationError
exception is slightly different from the other APIException
classes:
- The
detail
argument is mandatory, not optional. - The
detail
argument may be a list or dictionary of error details, and may also be a nested data structure. By using a dictionary, you can specify field-level errors while performing object-level validation in thevalidate()
method of a serializer. For example.raise serializers.ValidationError({'name': 'Please enter a valid name.'})
- By convention you should import the serializers module and use a fully qualified
ValidationError
style, in order to differentiate it from Django’s built-in validation error. For example.raise serializers.ValidationError('This field must be an integer value.')
The ValidationError
class should be used for serializer and field validation, and by validator classes. It is also raised when calling serializer.is_valid
with the raise_exception
keyword argument:
serializer.is_valid(raise_exception=True)
The generic views use the raise_exception=True
flag, which means that you can override the style of validation error responses globally in your API. To do so, use a custom exception handler, as described above.
By default this exception results in a response with the HTTP status code «400 Bad Request».
Generic Error Views
Django REST Framework provides two error views suitable for providing generic JSON 500
Server Error and
400
Bad Request responses. (Django’s default error views provide HTML responses, which may not be appropriate for an
API-only application.)
Use these as per Django’s Customizing error views documentation.
rest_framework.exceptions.server_error
Returns a response with status code 500
and application/json
content type.
Set as handler500
:
handler500 = 'rest_framework.exceptions.server_error'
rest_framework.exceptions.bad_request
Returns a response with status code 400
and application/json
content type.
Set as handler400
:
handler400 = 'rest_framework.exceptions.bad_request'
Third party packages
The following third-party packages are also available.
DRF Standardized Errors
The drf-standardized-errors package provides an exception handler that generates the same format for all 4xx and 5xx responses. It is a drop-in replacement for the default exception handler and allows customizing the error response format without rewriting the whole exception handler. The standardized error response format is easier to document and easier to handle by API consumers.
Исключения¶
Исключения… позволяют чисто организовать обработку ошибок в центральном или высокоуровневом месте в структуре программы.
‒ Doug Hellmann, Python Exception Handling Techniques
Представления фреймворка REST обрабатывают различные исключения и возвращают соответствующие ответы на ошибки.
Обрабатываемыми исключениями являются:
-
Подклассы
APIException
, поднятые внутри фреймворка REST. -
Исключение Django
Http404
. -
Исключение Django
PermissionDenied
.
В каждом случае фреймворк REST возвращает ответ с соответствующим кодом состояния и типом содержимого. В теле ответа будут содержаться любые дополнительные сведения о характере ошибки.
Большинство ответов на ошибки будут содержать ключ detail
в теле ответа.
Например, следующий запрос:
DELETE http://api.example.com/foo/bar HTTP/1.1 Accept: application/json
Может быть получен ответ об ошибке, указывающий на то, что метод DELETE
не разрешен на данном ресурсе:
HTTP/1.1 405 Method Not Allowed Content-Type: application/json Content-Length: 42 {"detail": "Method 'DELETE' not allowed."}
Ошибки валидации обрабатываются несколько иначе, и в качестве ключей в ответе будут указаны имена полей. Если ошибка валидации не относится к конкретному полю, то будет использован ключ «non_field_errors» или любое строковое значение, установленное для параметра NON_FIELD_ERRORS_KEY
.
Пример ошибки валидации может выглядеть следующим образом:
HTTP/1.1 400 Bad Request Content-Type: application/json Content-Length: 94 {"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}
Пользовательская обработка исключений¶
Вы можете реализовать пользовательскую обработку исключений, создав функцию-обработчик, которая преобразует исключения, возникающие в представлениях вашего API, в объекты ответа. Это позволит вам контролировать стиль ответов на ошибки, используемый вашим API.
Функция должна принимать пару аргументов, первый из которых — обрабатываемое исключение, а второй — словарь, содержащий любой дополнительный контекст, например, обрабатываемое в данный момент представление. Функция обработчика исключения должна либо вернуть объект Response
, либо вернуть None
, если исключение не может быть обработано. Если обработчик возвращает None
, то исключение будет повторно поднято и Django вернет стандартный ответ HTTP 500 „server error“.
Например, вы можете захотеть убедиться, что все ответы на ошибки включают код состояния HTTP в теле ответа, например, так:
HTTP/1.1 405 Method Not Allowed Content-Type: application/json Content-Length: 62 {"status_code": 405, "detail": "Method 'DELETE' not allowed."}
Чтобы изменить стиль ответа, вы можете написать следующий пользовательский обработчик исключений:
from rest_framework.views import exception_handler def custom_exception_handler(exc, context): # Call REST framework's default exception handler first, # to get the standard error response. response = exception_handler(exc, context) # Now add the HTTP status code to the response. if response is not None: response.data['status_code'] = response.status_code return response
Аргумент context не используется обработчиком по умолчанию, но может быть полезен, если обработчику исключения нужна дополнительная информация, например, обрабатываемое в данный момент представление, доступ к которому можно получить в виде context['view']
.
Обработчик исключений также должен быть настроен в ваших настройках, используя клавишу настройки EXCEPTION_HANDLER
. Например:
REST_FRAMEWORK = { 'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler' }
Если параметр 'EXCEPTION_HANDLER'
не указан, то по умолчанию используется стандартный обработчик исключений, предоставляемый фреймворком REST:
REST_FRAMEWORK = { 'EXCEPTION_HANDLER': 'rest_framework.views.exception_handler' }
Обратите внимание, что обработчик исключений будет вызываться только для ответов, сгенерированных поднятыми исключениями. Он не будет использоваться для любых ответов, возвращаемых непосредственно представлением, например, ответов HTTP_400_BAD_REQUEST
, которые возвращаются общими представлениями при неудачной проверке сериализатора.
Справочник по API¶
APIException¶
Подпись: APIException()
базовый класс для всех исключений, возникающих внутри класса APIView
или @api_view
.
Чтобы обеспечить пользовательское исключение, подкласс APIException
и установите атрибуты .status_code
, .default_detail
, и default_code
на класс.
Например, если ваш API полагается на сторонний сервис, который иногда может быть недоступен, вы можете захотеть реализовать исключение для кода ответа HTTP «503 Service Unavailable». Это можно сделать следующим образом:
from rest_framework.exceptions import APIException class ServiceUnavailable(APIException): status_code = 503 default_detail = 'Service temporarily unavailable, try again later.' default_code = 'service_unavailable'
Проверка исключений API¶
Существует ряд различных свойств, доступных для проверки состояния исключения API. Вы можете использовать их для создания пользовательской обработки исключений в вашем проекте.
Доступными атрибутами и методами являются:
-
.detail
— Возвращает текстовое описание ошибки. -
.get_codes()
— Возвращает идентификатор кода ошибки. -
.get_full_details()
— Возвращает как текстовое описание, так и идентификатор кода.
В большинстве случаев деталь ошибки будет простым элементом:
>>> print(exc.detail) You do not have permission to perform this action. >>> print(exc.get_codes()) permission_denied >>> print(exc.get_full_details()) {'message':'You do not have permission to perform this action.','code':'permission_denied'}
В случае ошибок валидации деталь ошибки будет представлять собой список или словарь элементов:
>>> print(exc.detail) {"name":"This field is required.","age":"A valid integer is required."} >>> print(exc.get_codes()) {"name":"required","age":"invalid"} >>> print(exc.get_full_details()) {"name":{"message":"This field is required.","code":"required"},"age":{"message":"A valid integer is required.","code":"invalid"}}
ParseError¶
Подпись: ParseError(detail=None, code=None)
Возникает, если запрос содержит неправильно сформированные данные при доступе к request.data
.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «400 Bad Request».
AuthenticationFailed¶
Подпись: AuthenticationFailed(detail=None, code=None)
Возникает, когда входящий запрос содержит неправильную аутентификацию.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «401 Unauthenticated», но оно также может привести к ответу «403 Forbidden», в зависимости от используемой схемы аутентификации. Более подробную информацию см. в authentication documentation.
NotAuthenticated¶
Подпись: NotAuthenticated(detail=None, code=None)
Возникает, когда неаутентифицированный запрос не прошел проверку на разрешение.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «401 Unauthenticated», но оно также может привести к ответу «403 Forbidden», в зависимости от используемой схемы аутентификации. Более подробную информацию см. в authentication documentation.
PermissionDenied¶
Подпись: PermissionDenied(detail=None, code=None)
Возникает, когда аутентифицированный запрос не прошел проверку на разрешение.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «403 Forbidden».
NotFound¶
Подпись: NotFound(detail=None, code=None)
Возникает, когда ресурс не существует по заданному URL. Это исключение эквивалентно стандартному исключению Django Http404
.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «404 Not Found».
MethodNotAllowed¶
Подпись: MethodNotAllowed(method, detail=None, code=None)
Возникает, когда происходит входящий запрос, который не сопоставлен с методом-обработчиком на представлении.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «405 Method Not Allowed».
Неприемлемо¶
Подпись: NotAcceptable(detail=None, code=None)
Возникает, когда поступает запрос с заголовком Accept
, который не может быть удовлетворен ни одним из доступных рендереров.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «406 Not Acceptable».
Дросселированный¶
Подпись: Throttled(wait=None, detail=None, code=None)
Возникает, когда входящий запрос не проходит проверку на дросселирование.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «429 Too Many Requests».
ValidationError¶
Подпись: ValidationError(detail, code=None)
Исключение ValidationError
несколько отличается от других классов APIException
:
-
Аргумент
detail
является обязательным, а не опциональным. -
Аргумент
detail
может представлять собой список или словарь сведений об ошибках, а также может быть вложенной структурой данных. Используя словарь, вы можете указать ошибки на уровне полей при выполнении проверки на уровне объектов в методеvalidate()
сериализатора. Например.raise serializers.ValidationError({'name': 'Please enter a valid name.'})
-
По соглашению вы должны импортировать модуль serializers и использовать полностью квалифицированный стиль
ValidationError
, чтобы отличить его от встроенной ошибки валидации Django. Например.raise serializers.ValidationError('This field must be an integer value.')
Класс ValidationError
следует использовать для сериализатора и валидации полей, а также классами валидаторов. Он также возникает при вызове serializer.is_valid
с аргументом ключевого слова raise_exception
:
serializer.is_valid(raise_exception=True)
Общие представления используют флаг raise_exception=True
, что означает, что вы можете переопределить стиль ответов на ошибки валидации глобально в вашем API. Для этого используйте пользовательский обработчик исключений, как описано выше.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «400 Bad Request».
Общие представления ошибок¶
Django REST Framework предоставляет два представления ошибок, подходящих для предоставления общих JSON 500
Server Error и 400
Bad Request ответов. (Стандартные представления ошибок Django предоставляют ответы в формате HTML, что может не подойти для приложения, использующего только API).
Используйте их в соответствии с Django’s Customizing error views documentation.
rest_framework.exceptions.server_error
¶
Возвращает ответ с кодом состояния 500
и типом содержимого application/json
.
Установить как handler500
:
handler500 = 'rest_framework.exceptions.server_error'
rest_framework.exceptions.bad_request
¶
Возвращает ответ с кодом состояния 400
и типом содержимого application/json
.
Установить как handler400
:
handler400 = 'rest_framework.exceptions.bad_request'
Вернуться на верх
-
Getting Help
-
el
-
es
-
fr
-
id
-
it
-
ja
-
ko
-
pl
-
pt-br
-
zh-hans
- Language: en
-
1.8
-
1.10
-
1.11
-
2.0
-
2.1
-
2.2
-
3.0
-
3.1
-
4.0
-
4.1
-
4.2
-
dev
-
Documentation version:
3.2
Error reporting¶
When you’re running a public site you should always turn off the
DEBUG
setting. That will make your server run much faster, and will
also prevent malicious users from seeing details of your application that can be
revealed by the error pages.
However, running with DEBUG
set to False
means you’ll never see
errors generated by your site – everyone will instead see your public error
pages. You need to keep track of errors that occur in deployed sites, so Django
can be configured to create reports with details about those errors.
Email reports¶
Server errors¶
When DEBUG
is False
, Django will email the users listed in the
ADMINS
setting whenever your code raises an unhandled exception and
results in an internal server error (strictly speaking, for any response with
an HTTP status code of 500 or greater). This gives the administrators immediate
notification of any errors. The ADMINS
will get a description of the
error, a complete Python traceback, and details about the HTTP request that
caused the error.
Note
In order to send email, Django requires a few settings telling it
how to connect to your mail server. At the very least, you’ll need
to specify EMAIL_HOST
and possibly
EMAIL_HOST_USER
and EMAIL_HOST_PASSWORD
,
though other settings may be also required depending on your mail
server’s configuration. Consult the Django settings
documentation for a full list of email-related
settings.
By default, Django will send email from root@localhost. However, some mail
providers reject all email from this address. To use a different sender
address, modify the SERVER_EMAIL
setting.
To activate this behavior, put the email addresses of the recipients in the
ADMINS
setting.
404 errors¶
Django can also be configured to email errors about broken links (404 “page
not found” errors). Django sends emails about 404 errors when:
DEBUG
isFalse
;- Your
MIDDLEWARE
setting includes
django.middleware.common.BrokenLinkEmailsMiddleware
.
If those conditions are met, Django will email the users listed in the
MANAGERS
setting whenever your code raises a 404 and the request has
a referer. It doesn’t bother to email for 404s that don’t have a referer –
those are usually people typing in broken URLs or broken Web bots. It also
ignores 404s when the referer is equal to the requested URL, since this
behavior is from broken Web bots too.
You can tell Django to stop reporting particular 404s by tweaking the
IGNORABLE_404_URLS
setting. It should be a list of compiled
regular expression objects. For example:
import re IGNORABLE_404_URLS = [ re.compile(r'.(php|cgi)$'), re.compile(r'^/phpmyadmin/'), ]
In this example, a 404 to any URL ending with .php
or .cgi
will not be
reported. Neither will any URL starting with /phpmyadmin/
.
The following example shows how to exclude some conventional URLs that browsers and
crawlers often request:
import re IGNORABLE_404_URLS = [ re.compile(r'^/apple-touch-icon.*.png$'), re.compile(r'^/favicon.ico$'), re.compile(r'^/robots.txt$'), ]
(Note that these are regular expressions, so we put a backslash in front of
periods to escape them.)
If you’d like to customize the behavior of
django.middleware.common.BrokenLinkEmailsMiddleware
further (for
example to ignore requests coming from web crawlers), you should subclass it
and override its methods.
See also
404 errors are logged using the logging framework. By default, these log
records are ignored, but you can use them for error reporting by writing a
handler and configuring logging appropriately.
Filtering error reports¶
Warning
Filtering sensitive data is a hard problem, and it’s nearly impossible to
guarantee that sensitive data won’t leak into an error report. Therefore,
error reports should only be available to trusted team members and you
should avoid transmitting error reports unencrypted over the Internet
(such as through email).
Filtering sensitive information¶
Error reports are really helpful for debugging errors, so it is generally
useful to record as much relevant information about those errors as possible.
For example, by default Django records the full traceback for the
exception raised, each traceback frame’s local variables, and the
HttpRequest
’s attributes.
However, sometimes certain types of information may be too sensitive and thus
may not be appropriate to be kept track of, for example a user’s password or
credit card number. So in addition to filtering out settings that appear to be
sensitive as described in the DEBUG
documentation, Django offers a
set of function decorators to help you control which information should be
filtered out of error reports in a production environment (that is, where
DEBUG
is set to False
): sensitive_variables()
and
sensitive_post_parameters()
.
-
sensitive_variables
(*variables)[source]¶ -
If a function (either a view or any regular callback) in your code uses
local variables susceptible to contain sensitive information, you may
prevent the values of those variables from being included in error reports
using thesensitive_variables
decorator:from django.views.decorators.debug import sensitive_variables @sensitive_variables('user', 'pw', 'cc') def process_info(user): pw = user.pass_word cc = user.credit_card_number name = user.name ...
In the above example, the values for the
user
,pw
andcc
variables will be hidden and replaced with stars (**********
)
in the error reports, whereas the value of thename
variable will be
disclosed.To systematically hide all local variables of a function from error logs,
do not provide any argument to thesensitive_variables
decorator:@sensitive_variables() def my_function(): ...
When using multiple decorators
If the variable you want to hide is also a function argument (e.g.
‘user
’ in the following example), and if the decorated function has
multiple decorators, then make sure to place@sensitive_variables
at the top of the decorator chain. This way it will also hide the
function argument as it gets passed through the other decorators:@sensitive_variables('user', 'pw', 'cc') @some_decorator @another_decorator def process_info(user): ...
-
sensitive_post_parameters
(*parameters)[source]¶ -
If one of your views receives an
HttpRequest
object
withPOST parameters
susceptible to
contain sensitive information, you may prevent the values of those
parameters from being included in the error reports using the
sensitive_post_parameters
decorator:from django.views.decorators.debug import sensitive_post_parameters @sensitive_post_parameters('pass_word', 'credit_card_number') def record_user_profile(request): UserProfile.create( user=request.user, password=request.POST['pass_word'], credit_card=request.POST['credit_card_number'], name=request.POST['name'], ) ...
In the above example, the values for the
pass_word
and
credit_card_number
POST parameters will be hidden and replaced with
stars (**********
) in the request’s representation inside the
error reports, whereas the value of thename
parameter will be
disclosed.To systematically hide all POST parameters of a request in error reports,
do not provide any argument to thesensitive_post_parameters
decorator:@sensitive_post_parameters() def my_view(request): ...
All POST parameters are systematically filtered out of error reports for
certaindjango.contrib.auth.views
views (login
,
password_reset_confirm
,password_change
, andadd_view
and
user_change_password
in theauth
admin) to prevent the leaking of
sensitive information such as user passwords.
Custom error reports¶
All sensitive_variables()
and sensitive_post_parameters()
do is,
respectively, annotate the decorated function with the names of sensitive
variables and annotate the HttpRequest
object with the names of sensitive
POST parameters, so that this sensitive information can later be filtered out
of reports when an error occurs. The actual filtering is done by Django’s
default error reporter filter:
django.views.debug.SafeExceptionReporterFilter
. This filter uses the
decorators’ annotations to replace the corresponding values with stars
(**********
) when the error reports are produced. If you wish to
override or customize this default behavior for your entire site, you need to
define your own filter class and tell Django to use it via the
DEFAULT_EXCEPTION_REPORTER_FILTER
setting:
DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'
You may also control in a more granular way which filter to use within any
given view by setting the HttpRequest
’s exception_reporter_filter
attribute:
def my_view(request): if request.user.is_authenticated: request.exception_reporter_filter = CustomExceptionReporterFilter() ...
Your custom filter class needs to inherit from
django.views.debug.SafeExceptionReporterFilter
and may override the
following attributes and methods:
-
class
SafeExceptionReporterFilter
[source]¶ -
-
cleansed_substitute
¶ -
New in Django 3.1.
The string value to replace sensitive value with. By default it
replaces the values of sensitive variables with stars
(**********
).
-
hidden_settings
¶ -
New in Django 3.1.
A compiled regular expression object used to match settings and
request.META
values considered as sensitive. By default equivalent
to:import re re.compile(r'API|TOKEN|KEY|SECRET|PASS|SIGNATURE', flags=re.IGNORECASE)
-
is_active
(request)[source]¶ -
Returns
True
to activate the filtering in
get_post_parameters()
andget_traceback_frame_variables()
.
By default the filter is active ifDEBUG
isFalse
. Note
that sensitiverequest.META
values are always filtered along with
sensitive setting values, as described in theDEBUG
documentation.
-
get_post_parameters
(request)[source]¶ -
Returns the filtered dictionary of POST parameters. Sensitive values
are replaced withcleansed_substitute
.
-
get_traceback_frame_variables
(request, tb_frame)[source]¶ -
Returns the filtered dictionary of local variables for the given
traceback frame. Sensitive values are replaced with
cleansed_substitute
.
-
New in Django 3.1.
If you need to customize error reports beyond filtering you may specify a
custom error reporter class by defining the
DEFAULT_EXCEPTION_REPORTER
setting:
DEFAULT_EXCEPTION_REPORTER = 'path.to.your.CustomExceptionReporter'
The exception reporter is responsible for compiling the exception report data,
and formatting it as text or HTML appropriately. (The exception reporter uses
DEFAULT_EXCEPTION_REPORTER_FILTER
when preparing the exception
report data.)
Your custom reporter class needs to inherit from
django.views.debug.ExceptionReporter
.
-
class
ExceptionReporter
[source]¶ -
-
html_template_path
¶ -
New in Django 3.2.
Property that returns a
pathlib.Path
representing the absolute
filesystem path to a template for rendering the HTML representation of
the exception. Defaults to the Django provided template.
-
text_template_path
¶ -
New in Django 3.2.
Property that returns a
pathlib.Path
representing the absolute
filesystem path to a template for rendering the plain-text
representation of the exception. Defaults to the Django provided
template.
-
get_traceback_data
()[source]¶ -
Return a dictionary containing traceback information.
This is the main extension point for customizing exception reports, for
example:from django.views.debug import ExceptionReporter class CustomExceptionReporter(ExceptionReporter): def get_traceback_data(self): data = super().get_traceback_data() # ... remove/add something here ... return data
-
get_traceback_html
()[source]¶ -
Return HTML version of exception report.
Used for HTML version of debug 500 HTTP error page.
-
get_traceback_text
()[source]¶ -
Return plain text version of exception report.
Used for plain text version of debug 500 HTTP error page and email
reports.
-
As with the filter class, you may control which exception reporter class to use
within any given view by setting the HttpRequest
’s
exception_reporter_class
attribute:
def my_view(request): if request.user.is_authenticated: request.exception_reporter_class = CustomExceptionReporter() ...
See also
You can also set up custom error reporting by writing a custom piece of
exception middleware. If you do write custom
error handling, it’s a good idea to emulate Django’s built-in error handling
and only report/log errors if DEBUG
is False
.
Back to Top
Исключения
Исключения… позволяют чисто организовать обработку ошибок в центральном или высокоуровневом месте в структуре программы.
— Даг Хеллманн, Python Exception Handling Techniques
Обработка исключений в представлениях DRF
Представления DRF обрабатывают различные исключения и возвращают соответствующие ответы на ошибки.
Обрабатываемыми исключениями являются:
- Подклассы
APIException
, возникающие внутри DRF. - Исключение Django
Http404
. - Исключение Django
PermissionDenied
.
В каждом случае DRF вернет ответ с соответствующим кодом состояния и типом содержимого. В теле ответа будут содержаться любые дополнительные сведения о характере ошибки.
Большинство ответов на ошибки будут содержать ключ detail
в теле ответа.
Например, следующий запрос:
DELETE http://api.example.com/foo/bar HTTP/1.1 Accept: application/json
Может быть получен ответ об ошибке, указывающий на то, что метод DELETE
не разрешен для данного ресурса:
HTTP/1.1 405 Method Not Allowed Content-Type: application/json Content-Length: 42 {"detail": "Method 'DELETE' not allowed."}
Ошибки валидации обрабатываются несколько иначе, и в качестве ключей в ответе будут указаны имена полей. Если ошибка валидации не относится к конкретному полю, то будет использоваться ключ «non_field_errors», или любое строковое значение, установленное для параметра NON_FIELD_ERRORS_KEY
.
Пример ошибки валидации может выглядеть следующим образом:
HTTP/1.1 400 Bad Request Content-Type: application/json Content-Length: 94 {"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}
Пользовательская обработка исключений
Вы можете реализовать пользовательскую обработку исключений, создав функцию-обработчик, которая преобразует исключения, возникающие в ваших представлениях API, в объекты ответа. Это позволяет вам контролировать стиль ответов на ошибки, используемый вашим API.
Функция должна принимать пару аргументов, первый из которых — обрабатываемое исключение, а второй — словарь, содержащий любой дополнительный контекст, например, обрабатываемое в данный момент представление. Функция обработчика исключения должна либо возвращать объект Response
, либо возвращать None
, если исключение не может быть обработано. Если обработчик возвращает None
, то исключение будет повторно поднято, и Django вернет стандартный ответ HTTP 500 "Server error"
.
Например, вы можете захотеть убедиться, что все ответы на ошибки включают код состояния HTTP в теле ответа, например, так:
HTTP/1.1 405 Method Not Allowed Content-Type: application/json Content-Length: 62 {"status_code": 405, "detail": "Method 'DELETE' not allowed."}
Чтобы изменить стиль ответа, вы можете написать следующий пользовательский обработчик исключений:
from rest_framework.views import exception_handler def custom_exception_handler(exc, context): # Call REST framework's default exception handler first, # to get the standard error response. response = exception_handler(exc, context) # Now add the HTTP status code to the response. if response is not None: response.data['status_code'] = response.status_code return response
Аргумент context
не используется обработчиком по умолчанию, но может быть полезен, если обработчику исключений нужна дополнительная информация, например, обрабатываемое в данный момент представление, доступ к которому можно получить как context['view']
.
Обработчик исключений также должен быть настроен в ваших настройках, используя ключ настройки EXCEPTION_HANDLER
. Например:
REST_FRAMEWORK = { 'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler' }
Если параметр 'EXCEPTION_HANDLER'
не указан, по умолчанию используется стандартный обработчик исключений, предоставляемый DRF:
REST_FRAMEWORK = { 'EXCEPTION_HANDLER': 'rest_framework.views.exception_handler' }
Обратите внимание, что обработчик исключений будет вызываться только для ответов, сгенерированных поднятыми исключениями. Он не будет использоваться для ответов, возвращаемых непосредственно представлением, таких как ответы HTTP_400_BAD_REQUEST
, которые возвращаются общими представлениями при неудачной проверке сериализатора.
API Reference
APIException
Сигнатура: APIException()
.
базовый класс для всех исключений, возникающих внутри класса APIView
или @api_view
.
Чтобы предоставить пользовательское исключение, подкласс APIException
и установите атрибуты .status_code
, .default_detail
и default_code
для класса.
Например, если ваш API полагается на сторонний сервис, который иногда может быть недоступен, вы можете захотеть реализовать исключение для кода ответа HTTP «503 Service Unavailable». Это можно сделать следующим образом:
from rest_framework.exceptions import APIException class ServiceUnavailable(APIException): status_code = 503 default_detail = 'Service temporarily unavailable, try again later.' default_code = 'service_unavailable'
Проверка исключений API
Существует ряд различных свойств, доступных для проверки состояния исключения API. Вы можете использовать их для создания пользовательской обработки исключений для вашего проекта.
Доступными атрибутами и методами являются:
.detail
— Возвращает текстовое описание ошибки..get_codes()
— Возвращает идентификатор кода ошибки..get_full_details()
— Возвращает как текстовое описание, так и идентификатор кода.
В большинстве случаев деталь ошибки будет простым элементом:
>>> print(exc.detail) You do not have permission to perform this action. >>> print(exc.get_codes()) permission_denied >>> print(exc.get_full_details()) {'message':'You do not have permission to perform this action.','code':'permission_denied'}
В случае ошибок валидации деталь ошибки будет представлять собой либо список, либо словарь элементов:
>>> print(exc.detail) {"name":"This field is required.","age":"A valid integer is required."} >>> print(exc.get_codes()) {"name":"required","age":"invalid"} >>> print(exc.get_full_details()) {"name":{"message":"This field is required.","code":"required"},"age":{"message":"A valid integer is required.","code":"invalid"}}
ParseError
Сигнатура: ParseError(detail=None, code=None)
.
Возникает, если запрос содержит неправильно сформированные данные при доступе к request.data
.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «400 Bad Request».
AuthenticationFailed
Сигнатура: AuthenticationFailed(detail=None, code=None)
.
Возникает, когда входящий запрос содержит неправильную аутентификацию.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «401 Unauthenticated», но оно также может привести к ответу «403 Forbidden», в зависимости от используемой схемы аутентификации. Более подробную информацию см. в документации authentication documentation.
NotAuthenticated
Сигнатура: NotAuthenticated(detail=None, code=None)
.
Возникает, когда неаутентифицированный запрос не прошел проверку на разрешение.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «401 Unauthenticated», но оно также может привести к ответу «403 Forbidden», в зависимости от используемой схемы аутентификации. Более подробную информацию см. в документации authentication documentation.
PermissionDenied
Сигнатура: PermissionDenied(detail=None, code=None)
.
Возникает, когда аутентифицированный запрос не прошел проверку на разрешение.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «403 Forbidden».
NotFound
Сигнатура: NotFound(detail=None, code=None)
.
Возникает, когда ресурс не существует по указанному URL. Это исключение эквивалентно стандартному исключению Http404
Django.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «404 Not Found».
MethodNotAllowed
Сигнатура: MethodNotAllowed(method, detail=None, code=None)
.
Возникает, когда происходит входящий запрос, который не сопоставлен с методом-обработчиком на представлении.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «405 Method Not Allowed».
Неприемлемо
Сигнатура: NotAcceptable(detail=None, code=None)
.
Возникает, когда поступает запрос с заголовком Accept
, который не может быть удовлетворен ни одним из доступных рендереров.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «406 Not Acceptable».
UnsupportedMediaType
Сигнатура: UnsupportedMediaType(media_type, detail=None, code=None)
.
Возникает, если при обращении к request.data
нет парсеров, способных обработать тип содержимого данных запроса.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «415 Unsupported Media Type».
Дроссель
Сигнатура: Throttled(wait=None, detail=None, code=None)
.
Возникает, когда входящий запрос не проходит проверку на дросселирование.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «429 Too Many Requests».
ValidationError
Сигнатура: ValidationError(detail=None, code=None)
.
Исключение ValidationError
немного отличается от других классов APIException
:
- Аргумент
detail
может быть списком или словарем деталей ошибки, а также может быть вложенной структурой данных. Используя словарь, вы можете указать ошибки на уровне полей при выполнении проверки на уровне объектов в методеvalidate()
сериализатора. Например.raise serializers.ValidationError({'name': 'Please enter a valid name.'})
. - По соглашению вы должны импортировать модуль
serializers
и использовать полностью определенныйValidationError
, чтобы отличить его от встроенной ошибки валидации Django. Например.raise serializers.ValidationError('Это поле должно быть целочисленным значением.')
.
Класс ValidationError
должен использоваться для сериализатора и валидации полей, а также классами валидаторов. Он также вызывается при вызове serializer.is_valid
с именованным аргументом raise_exception
:
serializer.is_valid(raise_exception=True)
Общие представления используют флаг raise_exception=True
, что означает, что вы можете переопределить стиль ответов на ошибки валидации глобально в вашем API. Для этого используйте пользовательский обработчик исключений, как описано выше.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «400 Bad Request».
Общие представления об ошибках
DRF предоставляет два представления ошибок, подходящих для предоставления общих JSON ответов 500
Server Error и 400
Bad Request. (Стандартные представления ошибок Django предоставляют HTML-ответы, которые могут не подойти для приложения, использующего только API).
Используйте их согласно Django’s Customizing error views documentation.
rest_framework.exceptions.server_error
Возвращает ответ с кодом состояния 500
и типом содержимого application/json
.
Устанавливается как handler500
:
handler500 = 'rest_framework.exceptions.server_error'
rest_framework.exceptions.bad_request
Возвращает ответ с кодом статуса 400
и типом содержимого application/json
.
Устанавливается как handler400
:
handler400 = 'rest_framework.exceptions.bad_request'
Пакеты сторонних производителей
Также доступны следующие пакеты сторонних производителей.
Стандартизированные ошибки ДРФ
Пакет drf-standardized-errors предоставляет обработчик исключений, который генерирует одинаковый формат для всех ответов 4xx и 5xx. Он является заменой стандартного обработчика исключений и позволяет настраивать формат ответа на ошибку без переписывания всего обработчика исключений. Стандартизированный формат ответа на ошибку легче документировать и проще обрабатывать потребителям API.
Исключения
Исключения… позволяют чисто организовать обработку ошибок в центральном или высокоуровневом месте в структуре программы.
Обработка исключений в представлениях DRF
Обработка исключений в представлениях DRF
Представления DRF обрабатывают различные исключения и возвращают соответствующие ответы на ошибки.
Обрабатываемыми исключениями являются:
-
Подклассы
APIException
, возникающие внутри DRF. -
Исключение Django
Http404
. -
Исключение Django
PermissionDenied
.
В каждом случае DRF вернет ответ с соответствующим кодом состояния и типом содержимого. В теле ответа будут содержаться любые дополнительные сведения о характере ошибки.
Большинство ответов на ошибки будут содержать ключ detail
в теле ответа.
Например, следующий запрос:
DELETE http://api.example.com/foo/bar HTTP/1.1
Может быть получен ответ об ошибке, указывающий на то, что метод DELETE
не разрешен для данного ресурса:
HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
{«detail»: «Method ‘DELETE’ not allowed.»}
Ошибки валидации обрабатываются несколько иначе, и в качестве ключей в ответе будут указаны имена полей. Если ошибка валидации не относится к конкретному полю, то будет использоваться ключ «non_field_errors», или любое строковое значение, установленное для параметра NON_FIELD_ERRORS_KEY
.
Пример ошибки валидации может выглядеть следующим образом:
Content-Type: application/json
{«amount»: [«A valid integer is required.»], «description»: [«This field may not be blank.»]}
Пользовательская обработка исключений
Пользовательская обработка исключений
Вы можете реализовать пользовательскую обработку исключений, создав функцию-обработчик, которая преобразует исключения, возникающие в ваших представлениях API, в объекты ответа. Это позволяет вам контролировать стиль ответов на ошибки, используемый вашим API.
Функция должна принимать пару аргументов, первый из которых — обрабатываемое исключение, а второй — словарь, содержащий любой дополнительный контекст, например, обрабатываемое в данный момент представление. Функция обработчика исключения должна либо возвращать объект Response
, либо возвращать None
, если исключение не может быть обработано. Если обработчик возвращает None
, то исключение будет повторно поднято, и Django вернет стандартный ответ HTTP 500 "Server error"
.
Например, вы можете захотеть убедиться, что все ответы на ошибки включают код состояния HTTP в теле ответа, например, так:
HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
{«status_code»: 405, «detail»: «Method ‘DELETE’ not allowed.»}
Чтобы изменить стиль ответа, вы можете написать следующий пользовательский обработчик исключений:
from rest_framework.views import exception_handler
def custom_exception_handler(exc, context):
# Call REST framework’s default exception handler first,
# to get the standard error response.
response = exception_handler(exc, context)
# Now add the HTTP status code to the response.
response.data[‘status_code’] = response.status_code
Аргумент context
не используется обработчиком по умолчанию, но может быть полезен, если обработчику исключений нужна дополнительная информация, например, обрабатываемое в данный момент представление, доступ к которому можно получить как context['view']
.
Обработчик исключений также должен быть настроен в ваших настройках, используя ключ настройки EXCEPTION_HANDLER
. Например:
‘EXCEPTION_HANDLER’: ‘my_project.my_app.utils.custom_exception_handler’
Если параметр 'EXCEPTION_HANDLER'
не указан, по умолчанию используется стандартный обработчик исключений, предоставляемый DRF:
‘EXCEPTION_HANDLER’: ‘rest_framework.views.exception_handler’
Обратите внимание, что обработчик исключений будет вызываться только для ответов, сгенерированных поднятыми исключениями. Он не будет использоваться для ответов, возвращаемых непосредственно представлением, таких как ответы HTTP_400_BAD_REQUEST
, которые возвращаются общими представлениями при неудачной проверке сериализатора.
Сигнатура: APIException()
.
базовый класс для всех исключений, возникающих внутри класса APIView
или @api_view
.
Чтобы предоставить пользовательское исключение, подкласс APIException
и установите атрибуты .status_code
, .default_detail
и default_code
для класса.
Например, если ваш API полагается на сторонний сервис, который иногда может быть недоступен, вы можете захотеть реализовать исключение для кода ответа HTTP «503 Service Unavailable». Это можно сделать следующим образом:
from rest_framework.exceptions import APIException
class ServiceUnavailable(APIException):
default_detail = ‘Service temporarily unavailable, try again later.’
default_code = ‘service_unavailable’
Существует ряд различных свойств, доступных для проверки состояния исключения API. Вы можете использовать их для создания пользовательской обработки исключений для вашего проекта.
Доступными атрибутами и методами являются:
-
.detail
— Возвращает текстовое описание ошибки. -
.get_codes()
— Возвращает идентификатор кода ошибки. -
.get_full_details()
— Возвращает как текстовое описание, так и идентификатор кода.
В большинстве случаев деталь ошибки будет простым элементом:
You do not have permission to perform this action.
>>> print(exc.get_codes())
>>> print(exc.get_full_details())
{‘message’:‘You do not have permission to perform this action.’,‘code’:‘permission_denied’}
В случае ошибок валидации деталь ошибки будет представлять собой либо список, либо словарь элементов:
{«name»:«This field is required.»,«age»:«A valid integer is required.»}
>>> print(exc.get_codes())
{«name»:«required»,«age»:«invalid»}
>>> print(exc.get_full_details())
{«name»:{«message»:«This field is required.»,«code»:«required»},«age»:{«message»:«A valid integer is required.»,«code»:«invalid»}}
Сигнатура: ParseError(detail=None, code=None)
.
Возникает, если запрос содержит неправильно сформированные данные при доступе к request.data
.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «400 Bad Request».
Сигнатура: AuthenticationFailed(detail=None, code=None)
.
Возникает, когда входящий запрос содержит неправильную аутентификацию.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «401 Unauthenticated», но оно также может привести к ответу «403 Forbidden», в зависимости от используемой схемы аутентификации. Более подробную информацию см. в документации
authentication documentation
.
Сигнатура: NotAuthenticated(detail=None, code=None)
.
Возникает, когда неаутентифицированный запрос не прошел проверку на разрешение.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «401 Unauthenticated», но оно также может привести к ответу «403 Forbidden», в зависимости от используемой схемы аутентификации. Более подробную информацию см. в документации
authentication documentation
.
Сигнатура: PermissionDenied(detail=None, code=None)
.
Возникает, когда аутентифицированный запрос не прошел проверку на разрешение.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «403 Forbidden».
Сигнатура: NotFound(detail=None, code=None)
.
Возникает, когда ресурс не существует по указанному URL. Это исключение эквивалентно стандартному исключению Http404
Django.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «404 Not Found».
Сигнатура: MethodNotAllowed(method, detail=None, code=None)
.
Возникает, когда происходит входящий запрос, который не сопоставлен с методом-обработчиком на представлении.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «405 Method Not Allowed».
Сигнатура: NotAcceptable(detail=None, code=None)
.
Возникает, когда поступает запрос с заголовком Accept
, который не может быть удовлетворен ни одним из доступных рендереров.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «406 Not Acceptable».
Сигнатура: UnsupportedMediaType(media_type, detail=None, code=None)
.
Возникает, если при обращении к request.data
нет парсеров, способных обработать тип содержимого данных запроса.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «415 Unsupported Media Type».
Сигнатура: Throttled(wait=None, detail=None, code=None)
.
Возникает, когда входящий запрос не проходит проверку на дросселирование.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «429 Too Many Requests».
Сигнатура: ValidationError(detail=None, code=None)
.
Исключение ValidationError
немного отличается от других классов APIException
:
-
Аргумент
detail
может быть списком или словарем деталей ошибки, а также может быть вложенной структурой данных. Используя словарь, вы можете указать ошибки на уровне полей при выполнении проверки на уровне объектов в методеvalidate()
сериализатора. Например.raise serializers.ValidationError({'name': 'Please enter a valid name.'})
. -
По соглашению вы должны импортировать модуль
serializers
и использовать полностью определенныйValidationError
, чтобы отличить его от встроенной ошибки валидации Django. Например.raise serializers.ValidationError('Это поле должно быть целочисленным значением.')
.
Класс ValidationError
должен использоваться для сериализатора и валидации полей, а также классами валидаторов. Он также вызывается при вызове serializer.is_valid
с именованным аргументом raise_exception
:
serializer.is_valid(raise_exception=True)
Общие представления используют флаг raise_exception=True
, что означает, что вы можете переопределить стиль ответов на ошибки валидации глобально в вашем API. Для этого используйте пользовательский обработчик исключений, как описано выше.
По умолчанию это исключение приводит к ответу с кодом состояния HTTP «400 Bad Request».
Общие представления об ошибках
Общие представления об ошибках
DRF предоставляет два представления ошибок, подходящих для предоставления общих JSON ответов 500
Server Error и 400
Bad Request. (Стандартные представления ошибок Django предоставляют HTML-ответы, которые могут не подойти для приложения, использующего только API).
rest_framework.exceptions.server_error
rest_framework.exceptions.server_error
Возвращает ответ с кодом состояния 500
и типом содержимого application/json
.
Устанавливается как handler500
:
handler500 = ‘rest_framework.exceptions.server_error’
rest_framework.exceptions.bad_request
rest_framework.exceptions.bad_request
Возвращает ответ с кодом статуса 400
и типом содержимого application/json
.
Устанавливается как handler400
:
handler400 = ‘rest_framework.exceptions.bad_request’
Пакеты сторонних производителей
Пакеты сторонних производителей
Также доступны следующие пакеты сторонних производителей.
Стандартизированные ошибки ДРФ
Стандартизированные ошибки ДРФ
Пакет
drf-standardized-errors
предоставляет обработчик исключений, который генерирует одинаковый формат для всех ответов 4xx и 5xx. Он является заменой стандартного обработчика исключений и позволяет настраивать формат ответа на ошибку без переписывания всего обработчика исключений. Стандартизированный формат ответа на ошибку легче документировать и проще обрабатывать потребителям API.