diff options
Diffstat (limited to 'api-guide/exceptions/index.html')
| -rw-r--r-- | api-guide/exceptions/index.html | 10 |
1 files changed, 9 insertions, 1 deletions
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 @@ <li>Django's <code>PermissionDenied</code> exception.</li> </ul> <p>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.</p> -<p>By default all error responses will include a key <code>detail</code> in the body of the response, but other keys may also be included.</p> +<p>Most error responses will include a key <code>detail</code> in the body of the response.</p> <p>For example, the following request:</p> <pre><code>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."} </code></pre> +<p>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 <code>NON_FIELD_ERRORS_KEY</code> setting.</p> +<p>Any example validation error might look like this:</p> +<pre><code>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."]} +</code></pre> <h2 id="custom-exception-handling">Custom exception handling</h2> <p>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.</p> <p>The function must take a single argument, which is the exception to be handled, and should either return a <code>Response</code> object, or return <code>None</code> if the exception cannot be handled. If the handler returns <code>None</code> then the exception will be re-raised and Django will return a standard HTTP 500 'server error' response.</p> |