美文网首页
Requests 和 Responses

Requests 和 Responses

作者: 爱修仙的道友 | 来源:发表于2019-04-25 12:08 被阅读0次

    Request parsing

    REST framework's Request objects provide flexible request parsing that allows you to treat requests with JSON data or other media types in the same way that you would normally deal with form data.

    .data

    request.data returns the parsed content of the request body. This is similar to the standard request.POST and request.FILESattributes except that:

    • It includes all parsed content, including file and non-file inputs.
    • It supports parsing the content of HTTP methods other than POST, meaning that you can access the content of PUT and PATCH requests.
    • It supports REST framework's flexible request parsing, rather than just supporting form data. For example you can handle incoming JSON data in the same way that you handle incoming form data.

    For more details see the parsers documentation.

    .query_params

    request.query_params is a more correctly named synonym for request.GET.

    For clarity inside your code, we recommend using request.query_params instead of the Django's standard request.GET. Doing so will help keep your codebase more correct and obvious - any HTTP method type may include query parameters, not just GETrequests.

    .parsers

    The APIView class or @api_view decorator will ensure that this property is automatically set to a list of Parser instances, based on the parser_classes set on the view or based on the DEFAULT_PARSER_CLASSES setting.

    Content negotiation

    The request exposes some properties that allow you to determine the result of the content negotiation stage. This allows you to implement behaviour such as selecting a different serialisation schemes for different media types.

    .accepted_renderer

    The renderer instance that was selected by the content negotiation stage.

    .accepted_media_type

    A string representing the media type that was accepted by the content negotiation stage.


    Authentication

    REST framework provides flexible, per-request authentication, that gives you the ability to:

    • Use different authentication policies for different parts of your API.
    • Support the use of multiple authentication policies.
    • Provide both user and token information associated with the incoming request.

    .user

    request.user typically returns an instance of django.contrib.auth.models.User, although the behavior depends on the authentication policy being used.

    If the request is unauthenticated the default value of request.user is an instance of django.contrib.auth.models.AnonymousUser.

    For more details see the authentication documentation.

    .auth

    request.auth returns any additional authentication context. The exact behavior of request.auth depends on the authentication policy being used, but it may typically be an instance of the token that the request was authenticated against.

    If the request is unauthenticated, or if no additional context is present, the default value of request.auth is None.

    For more details see the authentication documentation.

    .authenticators

    The APIView class or @api_view decorator will ensure that this property is automatically set to a list of Authentication instances, based on the authentication_classes set on the view or based on the DEFAULT_AUTHENTICATORS setting.

    You won't typically need to access this property.

    Browser enhancements

    REST framework supports a few browser enhancements such as browser-based PUT, PATCH and DELETE forms.

    .method

    request.method returns the uppercased string representation of the request's HTTP method.

    Browser-based PUT, PATCH and DELETE forms are transparently supported.

    For more information see the browser enhancements documentation.

    .content_type

    request.content_type, returns a string object representing the media type of the HTTP request's body, or an empty string if no media type was provided.

    You won't typically need to directly access the request's content type, as you'll normally rely on REST framework's default request parsing behavior.

    If you do need to access the content type of the request you should use the .content_type property in preference to using request.META.get('HTTP_CONTENT_TYPE'), as it provides transparent support for browser-based non-form content.

    For more information see the browser enhancements documentation.

    .stream

    request.stream returns a stream representing the content of the request body.

    You won't typically need to directly access the request's content, as you'll normally rely on REST framework's default request parsing behavior.


    Creating responses

    Response()

    Signature: Response(data, status=None, template_name=None, headers=None, content_type=None)

    Unlike regular HttpResponse objects, you do not instantiate Response objects with rendered content. Instead you pass in unrendered data, which may consist of any Python primitives.

    The renderers used by the Response class cannot natively handle complex datatypes such as Django model instances, so you need to serialize the data into primitive datatypes before creating the Response object.

    You can use REST framework's Serializer 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 also status codes.
    • template_name: A template name to use if HTMLRenderer 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.

    Attributes

    .data

    The unrendered, serialized data of the response.

    .status_code

    The numeric status code of the HTTP response.

    .content

    The rendered content of the response. The .render() method must have been called before .content can be 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 that will be used to render the response.

    Set automatically by the APIView or @api_view immediately before the response is returned from the view.

    .accepted_media_type

    The media type that was selected by the content negotiation stage.

    Set automatically by the APIView or @api_view immediately before the response is returned from the view.

    .renderer_context

    A dictionary of additional context information that will be passed to the renderer's .render() method.

    Set automatically by the APIView or @api_view immediately before the response is returned from the view.


    Standard HttpResponse attributes

    The Response class extends SimpleTemplateResponse, 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'
    

    .render()

    Signature: .render()

    As with any other TemplateResponse, 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 the accepted_renderer instance.

    You won't typically need to call .render() yourself, as it's handled by Django's standard response cycle.

    相关文章

      网友评论

          本文标题:Requests 和 Responses

          本文链接:https://www.haomeiwen.com/subject/webagqtx.html