@@ -217,6 +217,16 @@ Renders data into HTML for the Browsable API. This renderer will determine whic
...
@@ -217,6 +217,16 @@ Renders data into HTML for the Browsable API. This renderer will determine whic
**.charset**: `utf-8`
**.charset**: `utf-8`
## MultiPartRenderer
This renderer is used for rendering HTML multipart form data. **It is not suitable as a response renderer**, but is instead used for creating test requests, using REST framework's [test client and test request factory][testing].
*The following settings control the behavior of APIRequestFactory and APIClient*
#### TEST_REQUEST_DEFAULT_FORMAT
The default format that should be used when making test requests.
This should match up with the format of one of the renderer classes in the `TEST_REQUEST_RENDERER_CLASSES` setting.
Default: `'multipart'`
#### TEST_REQUEST_RENDERER_CLASSES
The renderer classes that are supported when building test requests.
The format of any of these renderer classes may be used when contructing a test request, for example: `client.post('/users', {'username': 'jamie'}, format='json')`
Default:
(
'rest_framework.renderers.MultiPartRenderer',
'rest_framework.renderers.JSONRenderer'
)
---
## Browser overrides
## Browser overrides
*Thefollowing settings provide URL or form-based overrides of the default browser behavior.*
*Thefollowing settings provide URL or form-based overrides of the default browser behavior.*
**TODO**: Document making requests. Note difference on form PUT requests. Document configuration.
## Creating test requests
The `APIRequestFactory` class supports an almost identical API to Django's standard `RequestFactory` class. This means the that standard `.get()`, `.post()`, `.put()`, `.patch()`, `.delete()`, `.head()` and `.options()` methods are all available.
### Using the format arguments
Methods which create a request body, such as `post`, `put` and `patch`, include a `format` argument, which make it easy to generate requests using a content type other than multipart form data. For example:
By default the available formats are `'multipart'` and `'json'`. For compatibility with Django's existing `RequestFactory` the default format is `'multipart'`.
To support a wider set of request formats, or change the default format, [see the configuration section][configuration].
If you need to explictly encode the request body, you can do so by explicitly setting the `content_type` flag. For example:
One difference worth noting between Django's `RequestFactory` and REST framework's `APIRequestFactory` is that multipart form data will be encoded for methods other than just `.post()`.
For example, using `APIRequestFactory`, you can make a form PUT request like so:
factory = APIRequestFactory()
request = factory.put('/notes/547/', {'title': 'remember to email dave'})
Using Django's `Factory`, you'd need to explicitly encode the data yourself:
When testing views directly using a request factory, it's often convenient to be able to directly authenticate the request, rather than having to construct the correct authentication credentials.
To forcibly authenticate a request, use the `force_authenticate()` method.
The signature for the method is `force_authenticate(request, user=None, token=None)`. When making the call, either or both of the user and token may be set.
---
**Note**: When using `APIRequestFactory`, the object that is returned is Django's standard `HttpRequest`, and not REST framework's `Request` object, which is only generated once the view is called.
This means that setting attributes directly on the request object may not always have the effect you expect. For example, setting `.token` directly will have no effect, and setting `.user` directly will only work if session authentication is being used.
# Request will only authenticate if `SessionAuthentication` is in use.
By default, requests created with `APIRequestFactory` will not have CSRF validation applied when passed to a REST framework view. If you need to explicitly turn CSRF validation on, you can do so by setting the `enforce_csrf_checks` flag when instantiating the factory.
**Note**: It's worth noting that Django's standard `RequestFactory` doesn't need to include this option, because when using regular Django the CSRF validation takes place in middleware, which is not run when testing views directly. When using REST framework, CSRF validation takes place inside the view, so the request factory needs to disable view-level CSRF checks.
The `APIClient` class supports the same request interface as `APIRequestFactory`. This means the that standard `.get()`, `.post()`, `.put()`, `.patch()`, `.delete()`, `.head()` and `.options()` methods are all available. For example:
To support a wider set of request formats, or change the default format, [see the configuration section][configuration].
## Authenticating
### .login(**kwargs)
### .login(**kwargs)
...
@@ -59,17 +146,23 @@ This can be a useful shortcut if you're testing the API but don't want to have t
...
@@ -59,17 +146,23 @@ This can be a useful shortcut if you're testing the API but don't want to have t
>>> client = APIClient()
>>> client = APIClient()
>>> client.force_authenticate(user=user)
>>> client.force_authenticate(user=user)
To unauthenticate subsequant requests, call `force_authenticate` setting the user and/or token to `None`.
To unauthenticate subsequent requests, call `force_authenticate` setting the user and/or token to `None`.
>>> client.force_authenticate(user=None)
>>> client.force_authenticate(user=None)
### Making requests
## CSRF validation
**TODO**: Document requests similarly to `APIRequestFactory`
By default CSRF validation is not applied when using `APIClient`. If you need to explicitly enable CSRF validation, you can do so by setting the `enforce_csrf_checks` flag when instantiating the client.
client = APIClient(enforce_csrf_checks=True)
As usual CSRF validation will only apply to any session authenticated views. This means CSRF validation will only occur if the client has been logged in by calling `login()`.
---
# Testing responses
# Testing responses
### Using request.data
## Checking the response data
When checking the validity of test responses it's often more convenient to inspect the data that the response was created with, rather than inspecting the fully rendered response.
When checking the validity of test responses it's often more convenient to inspect the data that the response was created with, rather than inspecting the fully rendered response.
...
@@ -83,7 +176,7 @@ Instead of inspecting the result of parsing `request.content`:
...
@@ -83,7 +176,7 @@ Instead of inspecting the result of parsing `request.content`:
If you're testing views directly using `APIRequestFactory`, the responses that are returned will not yet be rendered, as rendering of template responses is performed by Django's internal request-response cycle. In order to access `response.content`, you'll first need to render the response.
If you're testing views directly using `APIRequestFactory`, the responses that are returned will not yet be rendered, as rendering of template responses is performed by Django's internal request-response cycle. In order to access `response.content`, you'll first need to render the response.
...
@@ -92,6 +185,36 @@ If you're testing views directly using `APIRequestFactory`, the responses that a
...
@@ -92,6 +185,36 @@ If you're testing views directly using `APIRequestFactory`, the responses that a
response = view(request, pk='4')
response = view(request, pk='4')
response.render() # Cannot access `response.content` without this.
response.render() # Cannot access `response.content` without this.
The default format used to make test requests may be set using the `TEST_REQUEST_DEFAULT_FORMAT` setting key. For example, to always use JSON for test requests by default instead of standard multipart form requests, set the following in your `settings.py` file:
REST_FRAMEWORK = {
...
'TEST_REQUEST_DEFAULT_FORMAT': 'json'
}
## Setting the available formats
If you need to test requests using something other than multipart or json requests, you can do so by setting the `TEST_REQUEST_RENDERER_CLASSES` setting.
For example, to add support for using `format='yaml'` in test requests, you might have something like this in your `settings.py` file.