一、APIView

我们在使用DjangoRestfulFramework的时候会将每个视图类继承APIView，取代原生Django的View类

APIView的流程分析：

rest_framework>>views.py>>APIView

进入APIView

APIView>>as_view

走as_view方法(此方法会在Django启动时，在路由文件内执行，最终返回一个view函数内存地址) 

接下来我们回顾一下Django原生的as_view内的view方法内容：

或者通过代码点进去View，找到原生as_view：

from django.views import View

APIView>>dispatch

根据图片分析，最终会走到APIView中的dispatch方法，我们找到它：

 关键代码：initialize_request

 找到initialize_request（APIView内）

关键代码：initial

找到initial(APIView内)

 

接下来小结一下APIView大致流程：

　　APIView内的as_view>>原生Django的as_view方法，返回view函数内存地址，然后继续在APIView的as_view中返回这个view内存地址，同时这个view被装饰了一个禁用csrf的一个装饰器>>在成功匹配到路由进入视图函数时候，就会走view()执行，view会返回dispatch()，走APIView的dispatch方法>>在dispatch方法内通过Request类的封装，将原生Django的request对象封装到Request类中，实例化的request对象就是drf产生的新的request，同时还封装了3个重要的校验方法：权限、认证、频率>>最后dispatch方法根据getattr反射得到请求方式对应的我们写的类中的请求方法(比如请求是get就走get函数方法，是post就走post函数方法)，然后对请求进行处理、响应。

这里补充几个源码的处理细节：

APIView>>request对象

它是drf的Request类的对象

 

APIView>>request对象>>query_params

 

 继续挖掘：

Django原生的request对象

我们在一个视图类中打印一下type(request._request)

GET方法：

 GET方法小结：

Django原生request里面有个GET(以get形式提交的数据)，提交get数据时都拆到environ内部，Django把数据取出来转成了QueryDict的对象

引伸：session不是原生request对象的属性，它是在中间件中放进去的('django.contrib.sessions.middleware.SessionMiddleware')

DRF的Request类：

__getattr__方法重写：

二、Serializer序列化

 校验源码：is_valid()

首先需要知道，什么时候会走is_valid：调用了对象.is_valid（）时，会对反序列化的对象进行校验

进入is_valid源码：

注意我们是在BaseSerializer中找到的is_valid的

注意这里走run_validation时候，传入了initial_data，这个initial_data在BaseSerializer的__init__中有，

那么，需要分析一下：__init__在什么时候会触发，于是找BaseSerializer的子类发现都没有__init__，所以推出在视图类中反序列化得到对象的时候就触发了__init__,然后紧接着就进行了is_valid的校验

接下来继续进入run_validation：这里不要直接点了，直接点肯定是想上找，这里得从Serializer找，发现还真有：