一、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找，发现还真有：
