上篇回顾
为什么用Django rest_Framework框架？
----首先没有Django rest_Framework框架用django也是可以做出来的，只不过它为我们提供一些API常用的功能，比如：（认证，权限，限流，有了这些我们只需要写个类已配置，它就能当都市图用，还能全局配置，如果自己写还得写中间件，写装饰器来实现，通过Django rest_Framework框架，他已经把规则写好，只需要写类，只需实现方法，返回值就可以）实现了一部分功能。
哪些设计比较好？
----单独视图+全局配置 =>Dajngo中间件（importlib/反射）=>动态配置课扩展（短信，邮件，微信等提醒
问答：
版本这个东西哪里用？
- 版本更新迭代用 1.x 2.x
为什么要做前后端分离？
如果我们现在开发了一套 pc 端的页面。
现在要开发一套 ios 端的。
两个端显示应该是一样的。
如果你不前后端分离，你是不是要重复开发一套ios 端的。
如果使用前后分离，就简单多了。
而且，
django restful 框架
用的时候，只需配置写类就可以，像不像 stark 组件
所有组件都可以有全局和单视图的。
- 认证
- authenticate
- 有返回值：None(须配置),元组，raise
- 权限
- has_permission/has_object_permission
- 返回值： True表示有权限、False表示无权限
- 节流
- allow_request
- 内部原理：
- 默认放到 jdango 缓存中，以每个人自己的 ip 为 key，揭露访问时间。
- 根据当前时间与个数和配置文件中访问频率对比。
- 匿名用户和登录用户
- 版本
- urlpath/host
- 序列化
- 序列化
- 数据校验(即认证)
- 字段默认
- validates
- 钩子函数
- validate
本篇内容
- 分页
如果我数据量比较大，如何解决？
a. 记录一下最后一条的 idliru 102，先写上 id> 102，然后取下面 x 条。
b. 只显示120页
c. 对页码进行加密- 视图
只要有 self，一定都是从生成该对象的类开始找。
导入 GenericAPIView,这是个鸡肋。
重点来：
- from rest_framework import GenericViewSet
- 路由要修改下
- url(r'^index/$', views.IndexView.as_view({'get':'list'}))？？？？？？？？？？？？？？？？？？？？？？
- 增 - POST
- 删 - DELETE /users/id/
- 改
- PUT /users/id/
- PATCH 局部修改 /user/1/- 查 - GET /users/
如果要你查看某条的详细 你如何办？
- GET /uers/1/将请求变成对应关系，更方便的来完成路由操作。
*** 换方法，继承 ModelViewSet
这个它里面把增删改查的事全干了，你把对应关系找好就成。
如果你觉得他的不好，你也可以继承完后，自己写。
当你获取档条数据的时候，会调用你是否对当前对象有权限。
- has_object_permission()
from rest_framework.viewsets import ModelViewSet
进来之后：
class ModelViewSet(mixins.CreateModelMixin,
mixins.RetrieveModelMixin,
mixins.UpdateModelMixin,
mixins.DestroyModelMixin,
mixins.ListModelMixin,
GenericViewSet):
class CreateModelMixin(object):
def create(self, request, *args, **kwargs):
class RetrieveModelMixin(object):
def retrieve(self, request, *args, **kwargs):
class UpdateModelMixin(object):
def update(self, request, *args, **kwargs):
class DestroyModelMixin(object):
def destroy(self, request, *args, **kwargs):
class ListModelMixin(object):
def list(self, request, *args, **kwargs):
- 路由
一个 API 要写四个路由。
带参数、不带参数、带参数.json、不带参数.json- 渲染器
json 放到这。
知识点补充：
浏览器的一个请求从发送到返回都经历了什么，讲的越详细越好
1、先从网络模型层面：
client （浏览器）与 server 通过 http 协议通讯，http 协议属于应用层协议，http 基于 tcp 协议，所以 client 与 server 主要通过 socket 进行通讯；
而 tcp 属于传输层协议、如果走 https 还需要会话层 TLS、SSL 等协议； 传输层之下网络层，这里主要是路由协议 OSPF 等进行路由转发之类的。再向下数据链路层主要是 ARP、RARP 协议完成 IP 和 Mac 地址互解析，再向下到最底层物理层基本就是 IEEE 802.X 等协议进行数据比特流转成高低电平的的一些定义等等；
当浏览器发出请求，首先进行数据封包，然后数据链路层解析 IP 与 mac 地址的映射，然后上层网路层进行路由查表路由，通过应用层 DNS 协议得到目标地址对应的 IP ，在这里进行 n 跳的路由寻路；而传输层 tcp 协议可以说下比较经典的三次握手、四次分手的过程和状态机，这里放个图可以作为参考：
2、应用层方面：
数据交换主要通过 http 协议， http 协议是无状态协议，这里可以谈一谈 post、get 的区别以及 RESTFul 接口设计，然后可以讲服务器 server 模型 epoll、select 等，接着可以根据实际经验讲下 server 处理流程，比如我： server 这边 Nginx 拿到请求，进行一些验证，比如黑名单拦截之类的，然后 Nginx 直接处理静态资源请求，其他请求 Nginx 转发给后端服务器，这里我用 uWSGI, 他们之间通过 uwsgi 协议通讯，uWSGI 拿到请求，可以进行一些逻辑， 验证黑名单、判断爬虫等，根据 wsgi 标准，把拿到的 environs 参数扔给 Django ，Django 根据 wsgi 标准接收请求和 env， 然后开始 startresponse ，先跑 Django 相关后台逻辑，Django 拿到请求执行 request middleware 内的相关逻辑，然后路由到相应 view 执行逻辑，出错执行 exception middleware 相关逻辑，接着 response 前执行 response middleware 逻辑，最后通过 wsgi 标准构造 response， 拿到需要返回的东西，设置一些 headers，或者 cookies 之类的，最后 finishresponse 返回，再通过 uWSGI 给 Nginx ，Nginx 返回给浏览器。
