在上篇我们对Django原生View源码进行了局部解析:https://www.cnblogs.com/dongxixi/p/11130976.html
在前后端分离项目中前面我们也提到了各种认证需要自己来做,那么我们用rest_framework的时候
rest_framework也为我们提供相应的接口,rest_framework中的APIView实现了和Django原生View as_view()一样的功能
并在此基础上实现了原生request的封装、认证、权限、视图等等功能
我们来看APIView的as_view如何实现的:
通过上篇对View源码的分析我们可以得知,在View的的闭包函数view中调用了dispatch方法,那么我们在找dispatch的时候还是要从self开始找,
此时的self是我们在视图层定义的视图类的对象,视图类并没有定义dispatch,那么就找父类APIView,在APIView中我们找到了dispatch
那么意味着APIView对dispatch进行了重写,我们来看看APIView怎么封装的dispatch方法:
我们继续深入initialize_request()去看看它是怎么封装原生request的:
到这里,我们可以知道,它将原生的request和认证等组件给到Request类实例化返回,我们仍然需要进一步去看Request的源码:
这里我们可以得知,它将原生的request封装到了新的request对象的_request属性中,那么你就会想了,那原生request 的数据和方法都到哪里去了呢?
别着急,它也给你做了封装,继续看:
GET请求的数据:
它将原生GET请求的数据放到了query_parms里面,我们在视图类中通过request.query_parms就可以取到
POST请求数据:
这里的data不仅仅是POST的数据,所有请求方式的键值对数据的都会被放入data里面,支持urlencoded、form-data、json(application/json)
FILES数据:
对USER的封装:
此外还封装了auth等其他功能,这些功能不仅在新的request里面有,它也同样存在原生的request里,在该方法的解释上,它讲明了它支持Django底层contrib,并将user设置在了Django原生的HttpRequest实例中,以保证在任何Django原生中间件都可以通过校验,所以我们在使用APIView时可以几乎不用考虑兼容性问题
好了,我们刚刚看完了initialize_request()源码,了解了APIView对原生request进行如何进行封装之后
接下来我们来看initial是如何帮我们做认证、权限等校验的
首先我们来看认证校验:
按住Ctrl点进去之后发现它就一行代码