Django day24 cbv和APIView的源码分析 和 resful的规范

一：cbv的源码分析

　　　　1、CBV和FBV的区别：

　　　　　　- Class Base View   CBV(基于类的视图)
　　　　　　- Function Base View   FBV(基于函数的视图)

　　　　2、as_view与view的区别：

　　　　　　- def as_view： 类的方法
　　　　　　- def view：类方法内部，闭包函数定义：内层函数包含对外部作用域的引用

-def view(request,*args,**kwargs):
        self = cls(**initkwargs)
        if hasattr(self,'get') and not hasattr(self,'head'):
            self.head = self.get
        self.request = request
        self.args =args
        self.kwargs = kwargs
        # 不管一堆操作，最重要的还是这句话：执行dispatch方法
        # 是谁的dispatch方法？写的cbv的那个c，视图中的那个视图类
        # 这个类如果没有写dispatch，会执行View中的dispatch方法
        return self.dispatch(request,*args,**kwargs)

　　　　3、python中一切皆对象：函数也是对象

　　　　4、hasattr(self,'get')  -- 判断self类中是不是有该(get)方法

　　　　5、反射 setattr(self,get,get_all):相当于把get函数，变成了get_all
　　　　　　# 如果不写get方法，请求过来是，就会告诉你，这个方法不被允许
　　　　　　getattr(self,'get')：拿到get函数的内存地址

-def dispatch(self,request,*args,**kwargs):
        # request.method 前台请求的方法，转成了小写
        # http_method_name View 中定义的一个列表：是一堆请求方式
        if request.method.lower() in self.http_method_name:
            # getattr 的第三个参数是默认值：self.http_method_not_allowed
            # 拿到get方法的内存地址
            handler = getattr(self,request.mathod.lower(),aslf.http_method_not_allowed)
        else:
            handler = self.http_method_not_allowed
            # get(request,*args,**kwargs)
            *args,**kwargs 传入了这个参数，然后就会去执行get方法，self会自己传过来
            # 同理，执行post方法
        return handler(request,*args,**kwargs)

　　　　6、总结：请求来了---》as_view---》view---》dispatch---》分发到不同的函数，执行函数，拿到结果，然后返回

  比如说：我是get请求来的，在dispatch中做了分发
        handler(request,*args,**kwargs)执行这个是get，注意执行这个一定要有一个结果
                def dispatch(self,request,*args,**kwargs):
                #request,*args,**kwargs这堆参数一定要写上，request是必写，*args,**kwargs这两个分别是有名，无名分组
                        

二：resful的规范

　　1、什么是resful（定义）

　　　　是一个规范，简单的说，就是面向资源编程：把网络中所有东西，想象成资源

　　2、10种规范（*****）

　　　　（1）API与用户的通信协议，总是使用HTTPS协议；（2）域名；（3）版本；（4）路径；（5）method 请求方式；（6）过滤；（7）状态码；（8）错误处理；（9）返回结果；（10）返回结果中提供链接

　　1) 推荐使用HTTPS协议，，，API与用户的通信协议，总是使用HTTPS协议：HTTPS比HTTP安全

　　2) 域名：例如写一个查询所有图书的API接口

https://api.example.com/books	尽量将API部署在专用域名（会存在跨域问题）
https://127.0.0.1/api/books	API很简单（推荐使用这一种）

　　3)版本：每个接口都有一个版本，这只是一种规范，也可以不按照这样的方式来

URL，如：https://api.example.com/v1/books	https://api.example.com/v2/books (推荐用这种)
请求头	跨域时，引发发送多次请求

　  4）路径：网络上任何东西都是资源，均使用名词表示（可复数）

如：https://127.0.0.1/api/v1/books

　　https://127.0.0.1/api/v1/dogs

　　https://127.0.0.1/api/v1/apples

　　等等······

 注意不能这么写：http://127.0.0.1/api/get_all_books (获取所有图书)

 http://127.0.0.1/api/add_books (新增一本图书)

 统一都用这个：
https://127.0.0.1/api/v1/books

　　5）method（请求的方式）：https://127.0.0.1/api/v1/books用这一个接口就能承载以下的所有请求方案，通过不同的接口，一个请求能干很多事，通过请求的方式来表示是新增，获取，修改，删除资源

GET ：	从服务器取出资源，发一条get请求（一项或多项）
POST ：	在服务器新建一个资源，发一个post的请求
PUT ：	在服务器更新全部资源（修改），发一个put请求（客户端提供改变后的完整资源）
PATCH ：	在服务器更新局部资源（修改），发一个patch请求（客户端提供改变的属性）
DELETE ：	从服务器删除资源，发一个delete请求

　　6）过滤：前端过滤，https://127.0.0.1/api/v1/books?limit=10 前面还是一样的接口，后面可以传一个参数，指定返回的数量，比如limit=10，只拿10条数据（可以有过滤条件）

同理：

limit=10 指定返回记录的数据

offset=10 指定返回记录的开始位置

page=2&per_page=100 指定第几页和每页的记录数

name&order=asc 指定返回结果的属性排序和排序顺序

book_type_id=1 指定筛选条件

　　7）状态码：每次请求回去，都需要状态码，状态码可以自定义

1开头：正在处理

2开头：成功

3开头：重定向

4开头：客户端错误

5开头：服务器内部错误（这是后台程序写错了，直接去找bug就行了）

　　8）错误处理：应返回错误信息，error当做key

　　　　{status：100,，error：‘错误信息写上’}

　　9）返回结果：针对不同操作，服务器向用户返回的结果应该符合以下规范：

GET /books：返回资源对象的列表（数组）

GET /books/1：返回单个资源对象

POST /books：返回新生成的资源对象，新增--》传数据---》新增完成---》新的资源对象返回

PUT /books/1：返回完整的资源对象

PATCH /books/1：返回完整的资源对象

DELETE /books/1：返回一个空文档

　　　　　　相当于又请求了get一次，可以符合规范，也可以不符合，因为这只是一个规范

10）Hypermedia API，RESTful API最好做到Hypermedia，即返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么。

{
    status：100
    msg:成功
    url:https://127.0.0.1/books/1
}    

　　　　核心：返回结果中提供链接（在这一页的连接地址带一个上一页或下一页的链接地址，这样就不需要拼，直接取出后再发一次请求就可以了）

三：APIView源码分析

四：初识序列化