APIView
APIView是drf概念体系中最基本类视图，它基于Django的View，同时又实现了一层对自己创造的概念的封装，比如permission_classes，render_classes，authentication_classes等，相当于请求过来后又进入一层，过滤（验证、初始化）完要走的这些classes，才能执行到我们自己实现的view。
Mixin
在介绍Generic view前先说一下mixin。说白了，官方给的案例里面的mixin，就是对model的object增删改查的原子操作。比如RetrieveModelMixin，通过get_object先获取到对象，然后通过serializer拿到序列化数据。
延伸开来，Mixin是一个非常重要的概念，因为它是模块化拆分后最关键的原子逻辑实现，是每一个单独的块。试想下，我们可以通过这些小块拼接成不同的功能，比如用户注册功能，使用者有可能在手机注册，有可能在web注册，在Django后端中可能需要提供两套view层接口，甚至还有渲染template的实现，但是真正的逻辑处理上，可以只调用一个RegistMixin的东西，从而提高代码复用，降低维护成本。
甚至，Mixin可以重写同时继承的GenericAPIView中的实现，比如request参数处理，Response数据处理（视频、文件格式之类），get_queryset，get_serializer等等有通用需求，并且会在多个地方复用的定制，比如根据传入参数指定需要的serializer从而在mixin中重写get_serializer方法的实现逻辑。总之，原本会在View中发生的一切，都可以通过Mixin封装起来，或重写、或新的逻辑实现。
Generic views
典型的Generic view就是这样的，本质上是类视图，它由一些Mixin组成，这里的ListModelMixin实现了list()方法，并同时继承自GenericAPIView，同时自己实现了由get()到list()的转发。复杂的是，GenericAPIView实现，以及他的执行过程，和后期对里面函数的重写、定制。所以抽时间多研究下这里很值得，以后也会节省大量时间。
如果要实现的逻辑不是很复杂的话，直接在view中继承一个[List[Create[Update]]]APIView，然后指定下serializer_class，permission_class，queryset等就可以了。对drf熟悉的话相信这种方式实现功能会很快。
Viewsets
先看代码，ViewSet继承了ViewSetMixin和APIView，ViewSetMix是APIView中as_view的重写，实现请求到action的转发，虽然Django自带的View也实现了as_view，但只是传递初始化参数，确实没有这个请求转发到action的实现，APIView里面也没有。这里也可以学习到：Python的多重继承中，子类形参的先后顺序，影响到执行的是哪个类中的as_view方法，相当于ViewSetMixin又继承了APIView。
viewsets和APIView不一样的地方在于，它要表达的更多的是一个方法视图的集合，他的内部是已经实现了的list()，retrieve()，delete()，update()的实现，如果实现用drf的DefaultRouter。router和as_view都可以实现GET请求–>list()的转发，值得一提的还有detail_route和list_route(最新版本推荐使用action)，他们需要在urls中配置router的前提下使用，在Router类的get_url里面的get_routers执行，然后获得所有的路由列表，再进行action转发。
# account/views.pyclass AccountViewSet(viewsets.ModelViewSet): """ 对Account的操作的集合，本质上是基于方法视图的封装 """ queryset = User.objects.all() serializer_class = UserSerializer @detail_route(methods=['post'], url_path='change-password') def set_password(self, request, *args, **kwargs): """ 修改用户的密码 """ return Response(status=status.HTTP_200_OK) @detail_route(methods=['post'], url_path='change-username') def change_username(self, request, *args, **kwargs): """ 修改用户的用户名 """ return Response(status=status.HTTP_200_OK, data={'msg': 'changed'})# account/urls.pyrouter = routers.SimpleRouter()router.register(r'', views.AccountViewSet, base_name='user')urlpatterns = router.urls以上代码，直接实现了对account的增（create）删（delete）改（update）和account列表（list），同时我又添加了set_password和change_username方法。这种形式没接触过的话很难理解，但是却很实用，尤其一个model有频繁的不同功能需求的时候，如果写SetPasswordView和ChangeUsernameView这样类视图的实现，未免会很麻烦，这个时候viewsets就是很好的选择。
Serializersclass TopicListSerializer(serializers.ModelSerializer): class Meta: model = models.TopicModel fields = '__all__' read_only_fields = ('id', 'author_id')Serializer相当于View和Model的中间层，避免view频繁直接操作model object的同时，规范数据字段格式、内容、validator、提供序列化数据等等，同时可以定义方法实现对model的特定操作。serializer不适合处理业务逻辑，它要做的就是对数据传入传出的处理，保证数据正确。通常为了验证和序列化各项数据，serializer的代码加上validator也集中了较大的工作量。
其它
drf最主要的就是上面提到的一些概念，也许在刚接触Django Web的话没有接触过，但是这应该是drf中最常用的。其他的比如router、Throttling、validator也比较实用，甚至也是必须掌握的，但是drf的文档写的确定很详细，使用方法不再介绍。
总结
我的理解，drf是基于“Don’t repeat yourself”原则，提出一个Web开发的规范，它代码里提供了规范的接口，和最基础的使用例子，而在实际的复杂逻辑开发中，需要的是对各种概念的“custome”定制，几乎文档每一页都提供了定制的介绍。实际的应用里面不会是简单的增删改查，而是需要走一定的逻辑处理后的增删改查，同时还有对基础操作频繁的复用。drf通过把web业务系统中会出现的每一步流程拆分，进行模块化，概念化，让开发者知道需要开发的业务属于哪一种概念，放到哪一个模块下面，从而在drf的大框架下特定的位置编写，这样减少了一份功能多份代码实现的麻烦，也因为规范化coding提高了开发者的效率。
当然drf也有缺点，它对新手不够友好，一些封装太极致，以至于不容易明白程序的执行流程，比如我初次看viewsets、GenericAPIView的时候。