Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the context that was provided by the view to compute the response. The final output of the response is not computed until it is needed, later in the response process.
REST framework supports HTTP content negotiation by providing aResponse class which allows you to return content that can be rendered into multiple content types, depending on the client request.
TheResponse class subclasses Django'sSimpleTemplateResponse.Response objects are initialized with data, which should consist of native Python primitives. REST framework then uses standard HTTP content negotiation to determine how it should render the final response content.
There's no requirement for you to use theResponse class, you can also return regularHttpResponse orStreamingHttpResponse objects from your views if required. Using theResponse class simply provides a nicer interface for returning content-negotiated Web API responses, that can be rendered to multiple formats.
Unless you want to heavily customize REST framework for some reason, you should always use anAPIView class or@api_view function for views that returnResponse objects. Doing so ensures that the view can perform content negotiation and select the appropriate renderer for the response, before it is returned from the view.
Signature:Response(data, status=None, template_name=None, headers=None, content_type=None)
Unlike regularHttpResponse objects, you do not instantiateResponse objects with rendered content. Instead you pass in unrendered data, which may consist of any Python primitives.
The renderers used by theResponse class cannot natively handle complex datatypes such as Django model instances, so you need to serialize the data into primitive datatypes before creating theResponse object.
You can use REST framework'sSerializer classes to perform this data serialization, or use your own custom serialization.
Arguments:
data: The serialized data for the response.status: A status code for the response. Defaults to 200. See alsostatus codes.template_name: A template name to use ifHTMLRenderer is selected.headers: A dictionary of HTTP headers to use in the response.content_type: The content type of the response. Typically, this will be set automatically by the renderer as determined by content negotiation, but there may be some cases where you need to specify the content type explicitly.The unrendered, serialized data of the response.
The numeric status code of the HTTP response.
The rendered content of the response. The.render() method must have been called before.content can be accessed.
Thetemplate_name, if supplied. Only required ifHTMLRenderer or some other custom template renderer is the accepted renderer for the response.
The renderer instance that will be used to render the response.
Set automatically by theAPIView or@api_view immediately before the response is returned from the view.
The media type that was selected by the content negotiation stage.
Set automatically by theAPIView or@api_view immediately before the response is returned from the view.
A dictionary of additional context information that will be passed to the renderer's.render() method.
Set automatically by theAPIView or@api_view immediately before the response is returned from the view.
TheResponse class extendsSimpleTemplateResponse, and all the usual attributes and methods are also available on the response. For example you can set headers on the response in the standard way:
response = Response()response['Cache-Control'] = 'no-cache'Signature:.render()
As with any otherTemplateResponse, this method is called to render the serialized data of the response into the final response content. When.render() is called, the response content will be set to the result of calling the.render(data, accepted_media_type, renderer_context) method on theaccepted_renderer instance.
You won't typically need to call.render() yourself, as it's handled by Django's standard response cycle.