DRF提供的请求与响应类

一 内容协商

drf除了在数据序列化部分简写代码以外，还在视图中提供了简写操作。所以在django原有的django.views.View类基础上，drf封装了多个视图子类出来提供给我们使用。

Django REST framwork 提供的视图的主要作用：

• 控制序列化器的执行（检验、保存、转换数据）

• 控制数据库查询的执行

• 调用请求类和响应类[这两个类也是由drf帮我们再次扩展了一些功能类。]

在了解drf提供的请求与响应类之前，我们需要了解一个概念：内容协商。即：drf在django原有的基础上，新增了一个request对象内置到了drf提供的APIVIew视图类里面，并在django原有的HttpResponse响应类的基础上实现了一个子类rest_framework.response.Response响应类。这两个类，都是基于内容协商来完成数据的格式转换的。

drf中实现的内容协商流程：

DRF的request类->parser（http请求解析类）->识别客户端请求头中的Content-Type来完成数据转换成->类字典(QueryDict，字典的子类)

DRF的response类->renderer(http响应渲染类)->识别客户端请求头的"Accept"来提取客户端期望的返回数据格式-> 转换成客户端的期望格式数据

#！注意：django默认是没有实现内容协商的，所以我们如果希望使用内容协商，则要么手动给django提供这个功能，要么使用drf提供的视图类。

二 Request

REST framework 传入视图的request对象不再是Django默认的HttpRequest对象，而是REST framework提供的扩展了HttpRequest类的Request类的对象。REST framework 提供了Parserhttp请求解析器类，在接收到客户端的http请求后会自动根据Content-Type指明的请求数据类型（如JSON、html表单等）将请求数据进行parse解析，解析为类字典[QueryDict]对象保存到Request对象中。

Request对象的数据是自动根据前端发送数据的格式进行解析之后的结果。也就是说，无论前端发送的哪种格式的数据，我们都可以以统一的方式读取客户端提交的数据。

一 常用属性

1 .data

request.data 提供了Parse解析之后的请求体数据。类似于Django中标准的request.POST和 request.FILES、request.body属性，但提供如下特性：

• 包含了解析之后的文件和非文件数据
• 包含了对POST、PUT、PATCH请求方式解析后的数据
• 利用了REST framework的parser解析器，不仅支持表单类型数据，也支持JSON数据

2 .query_params

query_params，查询参数，也叫查询字符串(query string )
注意：request.query_params是不区分http请求方法的，只要是地址栏?号后面的查询字符串都可以接收，结果是QueryDict格式。
request.query_params本质上就是Django提供的request.GET，只是更换了更正确的名称而已。

3 request._reuqest

获取django内容的http请求处理对象（WSGIRequest的实例对象）。是Django视图类提供的request。

二 基本使用

视图代码：

"""django的原生视图类"""
from django.views import View
from django.http.response import JsonResponse

class StudentView(View):
    def get(self,request):
        print(request)  # <WSGIRequest: GET '/req/s1'>  from django.core.handlers.wsgi import WSGIRequest
        return JsonResponse({"name":"django视图返回的xiaoming"})

"""drf提供的API视图类"""
from rest_framework.views import APIView
from rest_framework.response import Response

class StudentAPIView(APIView):
    def get(self, request):
        print(request)  # <rest_framework.request.Request: GET '/req/s2'>
        print(request._request) # <WSGIRequest: GET '/req/s2'>
        """
        从上面可以看到，APIView类中提供的request对象是drf单独声明的，但是里面提供了_request属性的值是django视图类提供的request
        """
        print(request.query_params)
        return Response({"name": "xiaoming"})

    def post(self,request):
        """request提供了data属性，基于内容协商以统一的data属性来获取客户端以任何形式提交过来的数据"""
        print(request.data)
        # 如果客户端提交的是json数据，则request.data得到的数据是一个字典   {'name': 'xiaoming', 'age': 18, 'description': 'xxxxx'}
        # 如果客户端提交的是表单数据，则request.data得到的QueryDict类字典 <QueryDict: {'name': ['xiaohong'], 'age': ['20']}>
        print(request.query_params)
        return Response({"message": "ok"})

三 Response

一 构造方式

# import rest_framework.response.Response
Response(data, status=None, template_name=None, headers=None, content_type=None)

drf提供的响应处理类Response和请求处理类Request类不一样，Response就是django的HttpResponse响应处理类的子类。

data数据不要是render处理之后的数据，只需传递python的基本数据即可，REST framework会使用renderer渲染器处理data。

data不能是复杂结构的数据，如Django的模型类对象，对于这样的数据我们可以使用Serializer序列化器序列化处理后（转为了Python字典类型）再传递给data参数。

参数说明：

• data: 为响应准备的序列化处理后的数据；

• status: 状态码，默认200

• template_name: 模板名称，如果使用HTMLRenderer 时需指明；

• headers: 用于存放响应头信息的字典；

• content_type: 响应数据的Content-Type，通常此参数无需传递，REST framework会根据前端所需类型数据来设置该参数。

二 常用属性

1 .data

传给response对象的序列化后，但尚未render处理的数据

2 .status_code

状态码的数字

3 .content

经过render处理后的响应数据

三 状态码

为了方便设置状态码，REST framewrok在rest_framework.status模块中提供了常用http状态码的常量。

1 信息告知 - 1xx

HTTP_100_CONTINUE
HTTP_101_SWITCHING_PROTOCOLS

2 成功 - 2xx

HTTP_200_OK
HTTP_201_CREATED
HTTP_202_ACCEPTED
HTTP_203_NON_AUTHORITATIVE_INFORMATION
HTTP_204_NO_CONTENT
HTTP_205_RESET_CONTENT
HTTP_206_PARTIAL_CONTENT
HTTP_207_MULTI_STATUS

3 重定向 - 3xx

HTTP_300_MULTIPLE_CHOICES
HTTP_301_MOVED_PERMANENTLY
HTTP_302_FOUND
HTTP_303_SEE_OTHER
HTTP_304_NOT_MODIFIED
HTTP_305_USE_PROXY
HTTP_306_RESERVED
HTTP_307_TEMPORARY_REDIRECT

4 客户端错误 - 4xx

HTTP_400_BAD_REQUEST
HTTP_401_UNAUTHORIZED
HTTP_402_PAYMENT_REQUIRED
HTTP_403_FORBIDDEN
HTTP_404_NOT_FOUND
HTTP_405_METHOD_NOT_ALLOWED
HTTP_406_NOT_ACCEPTABLE
HTTP_407_PROXY_AUTHENTICATION_REQUIRED
HTTP_408_REQUEST_TIMEOUT
HTTP_409_CONFLICT
HTTP_410_GONE
HTTP_411_LENGTH_REQUIRED
HTTP_412_PRECONDITION_FAILED
HTTP_413_REQUEST_ENTITY_TOO_LARGE
HTTP_414_REQUEST_URI_TOO_LONG
HTTP_415_UNSUPPORTED_MEDIA_TYPE
HTTP_416_REQUESTED_RANGE_NOT_SATISFIABLE
HTTP_417_EXPECTATION_FAILED
HTTP_422_UNPROCESSABLE_ENTITY
HTTP_423_LOCKED
HTTP_424_FAILED_DEPENDENCY
HTTP_428_PRECONDITION_REQUIRED
HTTP_429_TOO_MANY_REQUESTS
HTTP_431_REQUEST_HEADER_FIELDS_TOO_LARGE
HTTP_451_UNAVAILABLE_FOR_LEGAL_REASONS

5 服务器错误 - 5xx

HTTP_500_INTERNAL_SERVER_ERROR
HTTP_501_NOT_IMPLEMENTED
HTTP_502_BAD_GATEWAY
HTTP_503_SERVICE_UNAVAILABLE
HTTP_504_GATEWAY_TIMEOUT
HTTP_505_HTTP_VERSION_NOT_SUPPORTED
HTTP_507_INSUFFICIENT_STORAGE
HTTP_511_NETWORK_AUTHENTICATION_REQUIRED