一：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源码分析
四：初识序列化