Responses
与基本的HttpResponse对象不同，TemplateResponse对象保留 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.
The REST framework supports HTTP content negotiation by providing a Responseclass that allows you to return content that can be rendered into multiple content types based on client requests.
Response class is a subclass of Django- SimpleTemplateResponse. Response objects are initialised with data, which should consist of native Python primitives. The REST framework then uses standard HTTP content negotiation to determine how to render the final response content.
You don't need to use Responseclasses, you can also return regular HttpResponseor StreamingHttpResponseobjects from the view if needed. Using the Response class simply provides a nicer interface for returning content-negotiated Web API responses, that can be rendered to multiple formats.
Unless for some reason you want to customize your REST framework a lot, you should always use classes or functions Response for views that return objects . Doing this ensures that content negotiation is performed and an appropriate renderer is selected for the response before returning from the view.APIView@api_view
Creating responses
Response()
sign: Response(data, status=None, template_name=None, headers=None, content_type=None)
Unlike regular HttpResponseobjects, you don't need to instantiate Responseobjects with rendered content. Instead, pass unrendered data, which may consist of any Python primitives.
ResponseThe renderers used by the class cannot natively handle complex data types such as Django-model instances, so you need to Responseserialize the data to primitive data types before creating the object.
You can use REST framework's Serializerclasses to perform this data serialization, or use your custom serialization.
parameter:
data: The serialized data for the response.status: The status code of the response. Defaults to 200. See also status codes .template_name:HTMLRendererSelect the template name to use.headers: Dictionary of HTTP headers to use for the response.content_type: The content-type of the response. Usually, this will be set automatically by the renderer as determined by content negotiation, but in some cases you will need to specify the content type explicitly.
Attributes
.data
The unrendered content of a Request object.
.status_code
Numeric status code of the HTTP response.
.content
The rendered content of the response. .render()The method must .contentbe called before being accessed.
.template_name
The template_name, if supplied. Only required if HTMLRenderer or some other custom template renderer is the accepted renderer for the response.
.accepted_renderer
The renderer instance used to render the response.
Automatically set by APIViewor before returning a response from the view.@api_view
.accepted_media_type
The media type selected by the content negotiation stage.
Automatically set by APIViewor before returning a response from the view.@api_view
.renderer_context
.render()A dictionary of additional contextual information that will be passed to the renderer method.
Automatically set by APIViewor before returning a response from the view.@api_view
Standard HttpResponse attributes
ResponseThe class is extended SimpleTemplateResponseand all common properties and methods are available in the response. For example, you can set headers in the response in the standard way:
|
1
2
|
response
=
Response()
response[
'Cache-Control'
]
=
'no-cache'
|
.render（）
sign: .render()
Like any other TemplateResponse, this method renders the response's serialized data 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 the accepted_renderer instance.
Usually we don't need to call .render(), as it's handled by Django's standard response cycle.