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对象又是如何访问这些信息的

Drf模块详细分析

drf的请求模块

源码分析

内部核心：

drf的渲染模块

源码分析

drf的解析模块

源码分析

drf的异常模块

源码分析

核心及源码

猜你喜欢