APIView源码，Requset的源码简单分析

下载drf

使用

drf是基于cbv view的封装，所以必须写cbv

第一步：再写视图，必须写cbv

from rest_framework.views import APIView
class Books(APIView):
　　pass

-在setting中配置
INSTALLED_APPS= [
　　。。。。。
　　'rest_framework'
]

源码分析：

继承了APIView之后

-1 所有的请求都没有csrf的认证了，校验规则需要自己来做了

-2 在APIView中as_view本质还是调用了父类的as_view（View的as_view）

-3 as_view中调用dispatch -----》这个dispatch是APIView的dispatch

找dispatch不能直接点源码找先要在类里找类没有再去父类里面找

APIVIew的dispatch方法：

 .dispatch()与Django的常规调度非常相似，但是有额外的钩子用于启动、完成和异常处理。

self在哪个类里面self就是哪个类对象，self就是books的对象

这个Request类，是drf封装的

 

 实例化的时候传了一个request，传过来的request的原生的django的request对象，封装到了新的request对象里，封装成私有属性_request

 以后再用的request就是被封装的request，原生的request在request._request

 

里面

这三个东西是认证，权限，频率

这里里面request是封装后的request

 

新的request为啥能点出原来的属性

 

内部反射在原生的request取出GET,POST，因为Request重写了__getattr__方法，跟原来用法一样

原生django只能处理urlencodeed和fordata编码，如果是json格式原生django是不能处理的，需要自己从body中取出来自行处理

可以都用request.data

请求里面可以带过滤条件这里就是用到query_params是原来django原生的GET的数据

上传的文件是从FILES中取

总结

-源码分析：
    继承了APIView 之后：
    -1 所有的请求都没有csrf的认证了
    -2 在APIView中as_view本质还是调用了父类的as_view（View的as_view）
    -3 as_view中调用dispatch  -----》这个dispatch是APIView的dispatch

-APIVIew的dispatch方法：
    -1 对原生request对象做了一层包装（面向对象的封装），以后再用的request对象都新的request对象
    -2 在APIView中self.initial(request, *args, **kwargs)，里面有频率控制，权限控制和认证相关
    -3 根据请求方法执行咱们写的视图类中的相应方法
        --视图类中方法的request对象，已经变成了封装后的request
-Request类：
    -1 原生的request是self._request
    -2 取以post形式提交的数据，从request.data中取（urlencoded，formdata，json格式）
    -3 query_params 就是原生request的GET的数据
    -4 上传的文件是从FILES中取
    -5 （重点）其他的属性，直接request.属性名（因为重写了__getattr__方法）