From d8dbd8679080035de4e785a8e7b998fb01f4052b Mon Sep 17 00:00:00 2001 From: Xavier Ordoquy Date: Sat, 10 Jan 2015 10:41:12 +0100 Subject: Update documentation --- api-guide/exceptions/index.html | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'api-guide/exceptions') diff --git a/api-guide/exceptions/index.html b/api-guide/exceptions/index.html index a0734a14..f9403f1d 100644 --- a/api-guide/exceptions/index.html +++ b/api-guide/exceptions/index.html @@ -442,7 +442,7 @@
  • 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.

    -

    By default all error responses will include a key detail in the body of the response, but other keys may also be included.

    +

    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
    @@ -454,6 +454,14 @@ 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.

    +

    Any 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 single argument, which is the exception to be handled, and 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.

    -- cgit v1.2.3