APIView

1. Web应用模式

在开发Web应用中，有两种应用模式：

1. 前后端不分离[客户端看到的内容和所有界面效果都是由服务端提供出来的。

2. 前后端分离【把前端的界面效果(html，css，js分离到另一个服务端，python服务端只需要返回数据即可)】

前端形成一个独立的网站，服务端构成一个独立的网站

2. api接口

应用程序编程接口（Application Programming Interface，API接口），就是应用程序对外提供了一个操作数据的入口，这个入口可以是一个函数或类方法，也可以是一个url地址或者一个网络地址。当客户端调用这个入口，应用程序则会执行对应代码操作，给客户端完成相对应的功能。

当然，api接口在工作中是比较常见的开发内容，有时候，我们会调用其他人编写的api接口，有时候，我们也需要提供api接口给其他人操作。由此就会带来一个问题，api接口往往都是一个函数、类方法、或者url或其他网络地址，不断是哪一种，当api接口编写过程中，我们都要考虑一个问题就是这个接口应该怎么编写？接口怎么写的更加容易维护和清晰，这就需要大家在调用或者编写api接口的时候要有一个明确的编写规范！！！

为了在团队内部形成共识、防止个人习惯差异引起的混乱，我们都需要找到一种大家都觉得很好的接口实现规范，而且这种规范能够让后端写的接口，用途一目了然，减少客户端和服务端双方之间的合作成本。

目前市面上大部分公司开发人员使用的接口实现规范主要有：restful、RPC。

restful: 翻译成中文: 资源状态转换.(表征性状态转移)

• 把服务端提供的所有的数据/文件都看成资源， 那么通过api接口请求数据的操作，本质上来说就是对资源的操作了.

因此，restful中要求，我们把当前接口对外提供哪种资源进行操作，就把资源的名称写在url地址。

• web开发中操作资源，最常见的最通用的无非就是增删查改，所以restful要求在地址栏中声明要操作的资源是什么。然后通过http请求动词来说明对该资源进行哪一种操作

POST http://www.xxx.com/api/students/ 添加学生数据
GET http://www.xxx.com/api/students/ 获取所有学生
GET http://www.xxx.com/api/students/<pk>/ 获取id=pk的学生
DELETE http://www.xxx.com/api/students/<pk>/ 删除id=pk的一个学生
PUT http://www.xxx.com/api/students/<pk>/ 修改一个学生的全部信息 [id,name,sex,age,]
PATCH http://www.xxx.com/api/students/<pk>/ 修改一个学生的部分信息[age]

也就是说，我们仅需要通过url地址上的资源名称结合HTTP请求动作，就可以说明当前api接口的功能是什么了。restful是以资源为主的api接口规范，体现在地址上就是资源就是以名词表达。

3. RESTful API规范

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征）性状态转移。 它首次出现在2000年Roy Fielding的博士论文中。

RESTful是一种专门为Web 开发而定义API接口的设计风格，尤其适用于前后端分离的应用模式中。

这种风格的理念认为后端开发任务就是提供数据的，对外提供的是数据资源的访问接口，所以在定义接口时，客户端访问的URL路径就表示这种要操作的数据资源。

而对于数据资源分别使用POST、DELETE、GET、UPDATE等请求动作来表达对数据的增删查改。

GET	/students	获取所有学生
请求方法	请求地址	后端操作
POST	/students	增加学生
GET	/students/<pk>	获取编号为pk的学生
PUT	/students/<pk>	修改编号为pk的学生
DELETE	/students/<pk>	删除编号为pk的学生

restful规范是一种通用的规范，不限制语言和开发框架的使用。事实上，我们可以使用任何一门语言，任何一个框架都可以实现符合restful规范的API接口。

参考文档：http://www.runoob.com/w3cnote/restful-architecture.html

幂等性

接口实现过程中，会存在幂等性。所谓幂等性是指代客户端发起多次同样请求时，是否对于服务端里面的资源产生不同结果。如果多次请求，服务端结果还是一样，则属于幂等接口，如果多次请求，服务端产生结果是不一样的，则属于非幂等接口。

请求方式	是否幂等	是否安全
GET	幂等	安全
POST	不幂等	不安全
PUT/PATCH	幂等	不安全
DELETE	幂等	不安全

4. Django的CBV

之前我们用的Django的视图函数叫FBV（也就是函数型视图函数），这里我们来试试CBV（类视图函数）的写法。类视图函数可以让代码看起来更简洁，用起来更方便。

4.1 CBV的简单使用

视图类：

classBookView(View):
​
    defget(self, request):
        returnHttpResponse("get请求book")
​
    defpost(self, request):
        returnHttpResponse("post请求book")

路由：

urlpatterns= [
    path('book/', views.BookView.as_view()),
]

postman测试get请求：

postman测试post请求：

4.2 CBV的源码解析

4.2.1 面向对象知识点回顾

（1）继承

class Animal(object):

    def __init__(self, name, age):
        self.name = name
        self.age = age
        self.sleep()  # 一定要明确self是谁

    def sleep(self):
        print("sleeping...")


class Dog(Animal):

    def wangwang(self):
        print("旺旺叫")

    def sleep(self):
        print("仰天睡...")


d = Dog("alex", 23)

（2）反射

class Animal(object):

    def __init__(self, name, age, init_func_str):
        self.name = name
        self.age = age

        func = getattr(self, init_func_str)
        func()

    def sleep(self):
        print("sleeping...")

class Dog(Animal):

    def wangwang(self):
        print("旺旺叫")

    def sleep(self):
        print("仰天睡...")


d = Dog("alex", 23, "sleep")

4.2.2 CBV的源码解析

''''
class BookView(View):

    def get(self, request):
        return HttpResponse("get请求book")

    def post(self, request):
        return HttpResponse("post请求book")
        
        
class View:
        @classonlymethod
        def as_view(cls):
    
            def view(request):
                self = cls()
                return self.dispatch(request, *args, **kwargs)
                
            return view
            
      def dispatch(self, request):
        
            handler = getattr(self, request.method.lower()) # 按请求方式分发       
            return handler(request, *args, **kwargs)

# 路由
path('book/', views.BookView.as_view()),
path('book/', View.view),

# 一旦用户发起请求，比如get请求访问/book/，得到的是get方法的响应结果

get请求访问/book/  =>  view()  =>   dispatch()  =>  get()  
''''

使用视图函数时，django完成URL解析之后，会直接把request对象以及URL解析器捕获的参数（比如re_path中正则表达捕获的位置参数或关键字参数）丢给视图函数，但是在类视图中，这些参数不能直接丢给一个类，所以就有了as_view方法，这个方法只做一件事就是返回一个闭包，这个闭包像视图函数一样接收url解析器传送过来的参数。

先摆个例子放开头，以供参考：

# urls.py
from blog.views import IndexView
 
urlpatterns = [
    re_path(r"^$", IndexView.as_view(), name="index"),
]
1、首先了解path和re_path的执行逻辑

进到path或re_path的定义处，可以看到他们都是partial类的实例，所以path和re_path都是对象，而不是普通函数。



当启动django项目时，程序执行到urlpatterns时，urlpatterns列表中的各项依次得到执行，由于re_path和path都是对象，当时，其实是调用对象中的__call__方法，执行的结果就是，每个path或re_path的调用都返回一个URLPattern类的实例对象（路径为django.urls.resolvers.URLPattern），如果打印一下re_path的执行结果，得到如下结果：

print(re_path(r"^$", IndexView.as_view(), name="index"))
执行结果：
>> <URLPattern '^$' [name='index']>  # 返回一个URLPattern对象
来看看URLPattern类的定义：
class URLPattern:
    def __init__(self, pattern, callback, default_args=None, name=None):
        self.pattern = pattern
        self.callback = callback  # the view
        self.default_args = default_args or {}
        self.name = name

可以看到，URLPattern类__init__方法中的各个参数基本上就对应了传入path或re_path中的参数，其中有个callback属性，就是保存了回调函数的引用。而在path或re_path执行的时候，第二个参数传入的是as_view()（注意传入的不是as_view，而是as_view()，as_view()会立即执行），as_view()执行完成后，返回一个闭包，所以，callback保存的是这个闭包的引用。每次当请求来临时，url解析器完成url的解析，匹配到相应的回调函数，然后执行。

这里要提醒一点是，as_view只会执行一次，就是django在项目启动后，之后所有请求的处理都是由as_view返回的闭包（也就是URLPattern实例对象中的回调函数）执行。

2、再来看看上面说的闭包是什么

首先给出as_view方法的完整源码

    @classonlymethod
    def as_view(cls, **initkwargs):"""Main entry point for a request-response process."""
        for key in initkwargs:
            if key in cls.http_method_names:
                raise TypeError("You tried to pass in the %s method name as a "
                                "keyword argument to %s(). Don't do that."
                                % (key, cls.__name__))
            if not hasattr(cls, key):
                raise TypeError("%s() received an invalid keyword %r. as_view "
                                "only accepts arguments that are already "
                                "attributes of the class." % (cls.__name__, key))
 
        def view(request, *args, **kwargs):
            self = cls(**initkwargs)  # 实例化一个类视图对象
            if hasattr(self, 'get') and not hasattr(self, 'head'):
                self.head = self.get
            self.setup(request, *args, **kwargs)  # 初始化实例属性，保存外面传来的参数
            if not hasattr(self, 'request'):
                raise AttributeError(
                    "%s instance has no 'request' attribute. Did you override "
                    "setup() and forget to call super()?" % cls.__name__
                )
            return self.dispatch(request, *args, **kwargs)
        view.view_class = cls
        view.view_initkwargs = initkwargs
 
        # take name and docstring from class
        update_wrapper(view, cls, updated=())
 
        # and possible attributes set by decorators
        # like csrf_exempt from dispatch
        update_wrapper(view, cls.dispatch, assigned=())
        return view
上面的代码有点多，但是有很多代码对理解as_view核心作用来说是无关紧要的，下面把代码提炼一下：

@classonlymethod
def as_view(cls, **initkwargs):
    def view(request, *args, **kwargs):
        self = cls(**initkwargs)  # 实例化一个类视图对象，cls指的就是我们自定义的类视图，比如开头例子中的IndexView,所以self指的就是IndexView的一个实例
        if hasattr(self, 'get') and not hasattr(self, 'head'):
            self.head = self.get
        self.setup(request, *args, **kwargs)  # 初始化实例属性
        if not hasattr(self, 'request'):
            raise AttributeError(
                "%s instance has no 'request' attribute. Did you override "
                "setup() and forget to call super()?" % cls.__name__
            )
        return self.dispatch(request, *args, **kwargs)
    return view  # 这就是上面说的闭包
可以看到as_view的定义中又定义了一个view函数，该函数接收三个参数，第一个是request对象，第二个是url解析器捕获的url中的位置参数，第三个是url解析器捕获的url中的关键字参数。返回的view函数就是上面所说的闭包。

先不看view函数内部的执行逻辑，而只关注django接收到请求后的处理逻辑。当django项目启动，调用path或re_path返回URLPattern实例对象，同时as_view函数得到执行，并返回view函数的引用，传递给URLPattern实例对象的callback属性，此时as_view方法的使命完成，之后每次当django接受到浏览器发来的请求，url解析器解析url后，将request对象和url中捕获的参数传递给匹配到的回调函数（即view函数），由view函数执行后续操作。

3、再看view函数内部执行逻辑

        def view(request, *args, **kwargs):
            self = cls(**initkwargs)  # 实例化一个类视图对象，cls指的是我们自定义的类视图，比如开头例子中的IndexView，所以self指的就是IndexView的一个实例
            if hasattr(self, 'get') and not hasattr(self, 'head'):
                self.head = self.get
            self.setup(request, *args, **kwargs)  # 初始化实例属性
            if not hasattr(self, 'request'):
                raise AttributeError(
                    "%s instance has no 'request' attribute. Did you override "
                    "setup() and forget to call super()?" % cls.__name__
                )
            return self.dispatch(request, *args, **kwargs)
view函数主要做了两件事情，一是实例化一个类视图对象，这个容易理解，是哪个类视图对象接收了请求那就实例化哪个。二是调用dispatch方法，根据http请求方法（比如get，post）分派处理函数，dispatch方法逻辑比较简单，但是却是理解类视图执行逻辑的关键点。先看下源码：

    def dispatch(self, request, *args, **kwargs):
        # Try to dispatch to the right method; if a method doesn't exist,
        # defer to the error handler. Also defer to the error handler if the
        # request method isn't on the approved list.
        if request.method.lower() in self.http_method_names:  # 把http方法改为小写，并判断该方法是否是合法的http方法
            handler = getattr(self, request.method.lower(), self.http_method_not_allowed)  # 在类视图中找到对应的处理方法，返回该方法的引用给handler
        else:
            handler = self.http_method_not_allowed
        return handler(request, *args, **kwargs)  # 执行相应的方法
很简单了，先把http方法改为小写，然后判断该方法是否在http_method_names列表中（该列表保存了所有合法的http方法的小写名称），如果判断请求方法是合法的，就从我们自定义的类视图对象中获取到该方法，将引用传给handler，然后返回该方法执行的结果。举例：浏览器发送来一个get请求，get存在于http_method_names列表中，所以是个合法的http方法，此时通过getattr获取到自定义类视图中的get方法，并将get方法的引用传给handler（所以我们需要在自定义类视图中定义get方法，否则dispatch找不到get方法，比如开头的例子中，我们需要在IndexView类中定义get方法），最后执行get方法，并返回执行结果。

5. Django_Rest_Framework

核心思想: 大量缩减编写api接口的代码

Django REST framework是一个建立在Django基础之上的Web 应用开发框架，可以快速的开发REST API接口应用。在REST framework中，提供了序列化器Serialzier的定义，可以帮助我们简化序列化与反序列化的过程，不仅如此，还提供丰富的类视图、扩展类、视图集来简化视图的编写工作。REST framework还提供了认证、权限、限流、过滤、分页、接口文档等功能支持。REST framework提供了一个API 的Web可视化界面来方便查看测试接口。

中文文档：https://q1mi.github.io/Django-REST-framework-documentation/#django-rest-framework

github: https://github.com/encode/django-rest-framework/tree/master

特点：

提供了定义序列化器Serializer的方法，可以快速根据 Django ORM 或者其它库自动序列化/反序列化；
提供了丰富的类视图、Mixin扩展类，简化视图的编写；
丰富的定制层级：函数视图、类视图、视图集合到自动生成 API，满足各种需要；
多种身份认证和权限认证方式的支持；[jwt]
内置了限流系统；
直观的 API web 界面；【方便我们调试开发api接口】
可扩展性，插件丰富

6. 环境安装与配置

DRF需要以下依赖：

• Python (3.5 以上)

• Django (2.2 以上)

DRF是以Django子应用的方式提供的，所以我们可以直接利用已有的Django环境而无需从新创建。（若没有Django环境，需要先创建环境安装Django）

前提是已经安装了django，建议安装在虚拟环境

# conda create -n drf