django rest-framework处理流程分析

首先django要明白django是一个MVC结构的web框架，MVC框架中，逻辑的处理流程集中在view层，这也就是我们在定义url的时候，都是指定url对应某个view，而对于view，通常又有view对象和view函数，初期很多时候，我们直接将url对应到某个函数，而rest-framework是采用view对象，因为对象可以封装更多的信息和操作，更重要的是可以继承，便于统一(联想到C和C++的区别)。
其实还要明白一点，对于一个框架，或者一种协议或者规范，其实就是指定了数据的格式和处理的流程，要使用这个框架或者协议，就要遵守这个框架流程。或许会问，对于规定好的框架，我们怎么定制和更改呢，就像rest-framework怎么嵌套到django中的呢？联想到python的装饰器，我们可以在django中的某两层中间增加一层我们自己的层次，来做我们的特定处理，比如对应请求方法是否合理的判断，参数是否正确，域名ip是否被禁止访问，只是要注意，我们新增的这层的输出一定只是原来上一层输出的一个过滤或者流程的截断，不能改变原来流程的输出，不然就会引入问题。下面以rest-framwork和django为例。

对于django，我们还要明白一点，流程的处理入口是django/core/handlers/wsgi.py中的WSGIHandler类的__call__函数，而不是我们定义的urls.py中的urlpatterns，这一点很重要，对于部分新手来说，很可能把urls.py中的urlpatterns当成http请求的入口。这里再次简单的说一下生产环境中，一个基于django框架的web服务的处理请求流程：

nginx作为接入层，通过其反向代理功能，监听80端口获取请求连接 -> 根据nginx配置，将请求交给后端服务器程序wsgi server ->wsgi server调用执行django的wsgi.py处理请求逻辑 -> WSGIHandler的__call__函数就是整个逻辑处理流程 -> 首先在WSGIHandler __init__中的加载中间件（中间件是一些列的类，这些类中有两大类函数，process_request和process_response，可以把它想象成一个装饰器，就是对request对象做处理，或者对response对象做处理） ->中间件处理request -> urlpatterns中指定的逻辑 -> 中间件处理response ->返回response

rest-framwork就是上面流程中的urlpatterns指定的逻辑层，这个逻辑层对应的操作无非就是http协议定义的那几个方法，get，put，post，patch，delete等，rest-framwork所作的就是将这几个方法封装到特定的类里面，同时在这些类里面增加了一些其他的函数，比如请求方法判定，权限鉴定等操作，用户使用rest-framework的时候就可以继承rest-framework中定义好的某个或者某些类，当然rest-framework也给用户留了很多定制的空间，也可以理解，在使用rest-framework时，我们必须实现其中的部分功能。下面就具体的部分类作说明。
假如urlpatterns中有如下的一个url组:

    url(
        r"^users/(?P<pk>.*?)/?$",
        users.UserRetrieveModelView.as_view(),
        name="user_details",
    ),
    url(
        r"^users/?$",
        users.UserCreateModelView.as_view(),
        name="user_create",
    ),

UserRetrieveModelView在users.py中定义如下

from rest-framework import generics
class UserRetrieveModelView(generics.RetrieveAPIView):
    #下面再解释为什么需要新增加这些属性 
    queryset = user.objects.filter()
    serializer_class = UserSerializer
    permission_classes = (
         permissions.IsAdminUser,
    )

RetrieveAPIView，顾名思义，就是用来查询的，所以这个类通常用来处理get请求，看看RetrieveAPIView类的源码

class RetrieveAPIView(mixins.RetrieveModelMixin, GenericAPIView):
    """
    Concrete view for retrieving a model instance.
    """
    def get(self, request, *args, **kwargs):
        return self.retrieve(request, *args, **kwargs)

我们通常在写代码的时候，会将自己的View继承自RetrieveAPIView等这一系列由rest-framework提供的类，然后dispatch去根据请求方法调用对应的方法，比如上面的get，get就会调用retrieve，下面分析retrieve函数。

class RetrieveModelMixin(object):
    """
    Retrieve a model instance.
    """
    def retrieve(self, request, *args, **kwargs):
        instance = self.get_object()
        serializer = self.get_serializer(instance)
        return Response(serializer.data)

retrieve单词的意思就是"查询，检索"，所以这个操作怎么对应于数据库中的select的呢？这一步其实就是对应于get_object函数，这个函数来源于哪儿呢？其实来自于GenericAPIView类，具体位置是rest-framwork/generics.py中的GenericAPIView类里面的get_object函数，当然我们也可以在我们的view类中重新定义GenericAPIView中提供的方法,或者自定义类中queryset，serializer_class，queryable_fields，permission_classes 等属性去定制我们自己的操作，因为这些属性都是这个框架中某些流程中固定会用到的。对于GenericAPIView中的get_object函数

    def get_object(self):
        """
        Returns the object the view is displaying.

        You may want to override this if you need to provide non-standard
        queryset lookups.  Eg if objects are referenced using multiple
        keyword arguments in the url conf.
        """
        queryset = self.filter_queryset(self.get_queryset())

        # Perform the lookup filtering.
        lookup_url_kwarg = self.lookup_url_kwarg or self.lookup_field

        assert lookup_url_kwarg in self.kwargs, (
            'Expected view %s to be called with a URL keyword argument '
            'named "%s". Fix your URL conf, or set the `.lookup_field` '
            'attribute on the view correctly.' %
            (self.__class__.__name__, lookup_url_kwarg)
        )

        filter_kwargs = {self.lookup_field: self.kwargs[lookup_url_kwarg]}
        obj = get_object_or_404(queryset, **filter_kwargs)

        # May raise a permission denied
        self.check_object_permissions(self.request, obj)

        return obj

这个get_object函数就会调用self.get_queryset()函数去获取我们自己定义的view类的queryset属性，然后通过制定的queryset查询数据库。这也就是为什么UserRetrieveModelView类定义了queryset属性的原因，因为get_object函数会调用到这个属性。queryset属性就是对应输出库的一个查询操作，所以也就是我们看到user.objects.filter()。

我们查询获得的是一个model的实例，要获取model的数据，那就得用到序列化类serializer，也就是retrieve函数中的第二个流程，我们可以指定自己的serializer去处理查询得到的，也就是UserRetrieveModelView中指定的UserSerializer类。UserSerializer类一般直接继承rest-framework/serializers.py中的ModelSerializer(Serializer)就是了，serializers使用时是需要和model绑定的，怎么绑定，具体就是通过类中class Meta指定model，具体例子如下：

from rest-framework.serializers import ModelSerializer
from models import users
class UserSerializer(ModelSerializer):
        class Meta:
            model = users

关于ModelSerializer的具体用法参见：http://www.django-rest-framework.org/tutorial/1-serialization/
这就是对generics.RetrieveAPIView的简单使用。

下面接着对generics.CreateAPIView进行分析，就如上面url的例子UserCreateModelView

from rest-framework import generics
class UserCreateModelView(generics.CreateAPIView):
    serializer_class = UserSerializer

创建用户的时候我们一般使用post，这时候dispatch方法就会调用post方法，而post方法在哪儿定义的呢？查看一下CreateAPIView的源码，通过继承关系我们可以发现，post其实是调用create，而create来源于CreateModelMixin类
class CreateAPIView(mixins.CreateModelMixin, GenericAPIView):
"""
Concrete view for creating a model instance.
"""
def post(self, request, *args, **kwargs):
return self.create(request, *args, **kwargs)

class CreateModelMixin(object):
    """
    Create a model instance.
    """
    def create(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        self.perform_create(serializer)
        headers = self.get_success_headers(serializer.data)
        return Response(serializer.data, status=status.HTTP_201_CREATED, headers=headers)

当然rest-framework中也提供了很多方法的组合类，比如rest-framework/generics.py中RetrieveUpdateDestroyAPIView类，这些内容的方法是依赖于rest-framework/generics.py中GenericAPIView中定义的方法的，我们只要重写这些方法，就可以将rest-framework按照场景需求应用到实际生产中。

另外，个人觉得，明白一点很重要，那就是软件领域的问题，都可以通过增加一个中间层去处理，其实就像python装饰器的原理。所以如果要修改某个类xxx方法，如果这个类被其他类继承了，那么直接去修改这个类的方法会导致其他类也跟着改变，所以我们可以直接继承这个类，然后重构类的这个xxx方法，如果我们不想完全重构，只是想新增部分操作，那么可以在新增操作之后，调用super(Fclass, cls).xxx(*args, *kwargs)，这就是面向对象的好处。
比如

class OrgCls(object):
    def xxx(*args, *kwargs):
        """
        do some thing
        """

class MyCls(OrgCls):
    def xxx(*args, *kwargs):
        """
            do some thing special
        """
        super(MyCls, self).xxx(*args, *kwargs)