Drf模块详细分析

drf的请求模块

• drf的request是在wdgi的request基础上再次封装

• wsgi的request作为drf的request一个属性：_request

• 新的request对旧的request做了完全兼容

• 新的request对数据解析更规范化：所有的拼接参数都能解析到query_params中，所有数据包都被解析到data中，query_params和data属于QueryDict类型，可以.dict() 转化成原生dict类型

  源码分析

• drf的APIView类：重写了as_view(),但主体逻辑还是调用父类View的as_view(),局部禁用csrf认证，重点：所有继承drf的基本视图类APIView的视图类，都不在做csrf认证校验

• drf的APIView类：重写了dispatch()，在内部对ruquest进行了二次封装：self.initialize_request(request,*args,**kwargs),

  实例：
      print(request)
      print(request._request.GET)
      print(request.META)
      print(request.META.get('HTTP_LLL'))
  

内部核心：

走drf的Request初始化方法__init__：self.request=request
drf的Request的getter方法__getattr__:先从self.request反射属性，没取到再冲drf的request中取

drf的渲染模块

• 可以在视图类中通过renderer_classes类属性对该视图的数据影响渲染做匹配（局部匹配)

• 可以在项目的配置文件的drf配置中通过DEFAULT_RENDERER_CLASSES对该视图的数据响应渲染做配置（全局配置）

• 如果一个视图类在有全局配置下，还进行了局部配置，优先走自己的局部配置

  源码分析

• 二次处理响应对象：APIView的dispatch方法-->self.finalize_response(request,response,*args,**kwargs)

• 获取渲染类对象：进入finalize_response方法-->self.perform_content_negotiation(request,force=True)

• 从配置文件中得到渲染类对象：perform_content_negotiation-->self.get_renderers()-->[renderer() for renderer in self.renderer_classes]

  局部：renderer_classes = [JSONRenderer,BrowsableAPIRenderer]
  
  全局:REST_FRAMEWORK = {
      # 渲染模块的全局配置：开发一般只配置json
      'DEFAULT_RENDERER_CLASSES': [
                  'rest_framework.renderers.JSONRenderer',]
  

drf的解析模块

服务的对象是数据包数据

• 可以在视图类中通过parser_classes类属性对该视图的数据包解析做配置（局部配置）

• 可以在项目的配置文件的drf配置中通过DEFAULT_PARSER_CLASSES对该视图的数据包解析做配置（全局配置）

  源码分析

• APIView的dispatch方法：self.initialize_request(request,*args,**kwargs)内部还提供了数据解析

• self.get_parser_context(request)提供要解析的数据,self.get_parsers()提供解析的类对象（内部从配置中找解析类)

  局部：parser_classes = [JSONParser, MultiPartParser, FormParser]
  
  全局: REST_FRAMEWORK ={'DEFAULT_PARSER_CLASSES': [
          'rest_framework.parsers.JSONParser',
          'rest_framework.parsers.FormParser',
          'rest_framework.parsers.MultiPartParser'
      ]}
  

drf的异常模块

重写异常模块的目的是记录异常信息(项目上线)

• 在settings的drf配置中配置EXCEPTION_HANDLER,指向自定义的exception_handler函数

• drf出现异常了，都会回调exception_handler函数，携带异常对象和异常相关信息内容，在exception_handler函数完成异信息的返回以及异常信息的logging日志

  源码分析

• 在APIView的dispatch方法中，有一个超大的try...except...，将代码运行异常都交给异常处理模块处理self.handle_exception(exc)

• 从配置中映射出配置处理异常的函数(自定义异常模块就是自定义配置指向自己的函数)：self.get_exception_handler()

• 异常函数exception_handler(exc,context)处理异常，就会走自己的：先交给系统处理（客户端异常），系统没处理（服务器异常），再自己处理

  异常信息都需要被logging记录，所以需要自定义，drf只处理客户端异常，服务器异常需要手动处理，统一处理结果

  def exception_handler(exc, context):
      response = drf_exception_handler(exc, context)
  
      if response is None: # drf没有处理的异常(服务器异常)
          return Response(status=status.HTTP_500_INTERNAL_SERVER_ERROR, data={
              'status': 6,
              'exc': '%s' % exc
          })
  
      # 项目阶段，要记录到日志文件
      return Response(status=response.status_code, data={
          'status': 7,
          # drf处理的客户端异常，原始处理方式是将异常信息放在response对象的data中，data的格式是{'datail': '具体的异常信息'}
          'exc': '%s' % response.data.get('detail')
      })
  
  全局：REST_FRAMEWORK ={['EXCEPTION_HANDLER': 'api.utils.exception_handler']}
  

  drf响应模块

  • Response类生成对象需要的参数，以及Response类的对象可以使用的属性

  • 参数：Response(data=响应的数据，status=响应的网络状态码，header=通过响应头再携带部分信息给前端)

  • 属性：response.data response.status_code response.status_text

    核心及源码

    源码：Response类的__init__方法
    核心：知道response对象产生可以传那些信息，response对象又是如何访问这些信息的