DRF第三天

#分为两种模式
    前后端不分离:前端的界面由后端渲染页面或者重定向，也可以说后端控制前端页面的展示，耦合度太高，适用于网页应用  不适用于app端因为app可能只需要返回数据
    前后端分离:后端只返回数据，前端负责接受数据 渲染页面，耦合度较低，后端只需要负责写接口，供前端调用数据

前后端交互信息的媒介
四个特点:
	长得像返回数据的url连接
    请求方式：get、post、put、patch、delete
	请求参数 json或者xml格式的数据
    返回数据 json或者xml格式的数据

用来测试接口的工具
针对post请求 有三种编码格式  前端给后端发数据  都在请求体里
	urlencode
    	发送数据格式：name=zhang&price=1000000   
        接受数据格式：request.POST
    formdata
    	发送数据格式：name=zhang&price=1000000   也可以发送文件数据
        接受数据格式：request.FILES  或者request.POST
    json
    	发送数据格式：{"name":"zhang","price":10000}
        接受数据格式：json.load（request.body）   
        request.body接受的是bytes  二进制数据

RESTfulAPI是一种定义web API接口的设计风格，用于前后端分离的模式中
重要的
1.采用httpps连接，有api关键字标识接口url，url中有数据版本
2.数据既是资源url最后面均使用名词（可复数）比如books  users
3.资源 *** 作由请求方法来决定，并返回信息
4.过滤
5.响应状态码：
	200请求成功 201请求并创建资源成功  301永久重定向  302 暂时重定向  403请求无权限  404 请求路径（资源）不存在 405 请求方法不存在  500服务器异常
6.错误处理 返回错误信息 error：xxx 

序列化：我们识别的数据转换成指定的格式（json）发送给他
反序列化：别人发过来的数据（json）格式，转换或者说还原成自己能识别的数据

他就是django的第三方app  本质是可以快速写接口

他要求django必须是2.2版本以上

视图函数的类必须继承View   from django.views import View
url里面url：utl(r'^index/',views.类名.as_view())
views.类名.as_view()  存放的是一个内存地址

源码逻辑为 ：
	1.入口是as_view，因为类名.方法 这个方法是谁的  不是类的  那么就去他的父类找
    2.父类找到了as_view  发现他最终返回return view ，view的内存地址
    3.view这个方法他定义了一个对象，（该对象传入类的对象），return 返回了self.dispatch 根据调用规则，对象》产生该对象的类》父类 寻找
    4.在父类View找到了dispatch   这个方法是核心
    5.dispatch他首先判断请求方法在不在后面那个列表里request.method.lower（） in 一个列表（列表为请求的八个方法）
    6.在的情况利用反射handler=getattr（对象，request.method.lower（），没有这个名字为字符串的函数或方法返回的值）   有这个字符串的方法就返回了一个内存地址给handler 不在 返回一个错误的方法的内存地址
    7.调用handler（）并返回  
    8.一级一级返回 

先下载restframework 直接settings里面下载  或者pip3 install djangorestframework
视图函数的类必须继承APIView   from rest_framework.views import APIView
url里面url：path(r'^index/',views.类名.as_view())
执行逻辑为：
	1.发现路由一样也是调用了as_view方法，按照调用顺序先去自己本身找，然后父类发现APIView继承了View 在父类APIView找到了as_view
    2.发现父类的as_view里面调用了super.as_view赋值给view  并把cls ，从新赋值，return了新的csrf_exempt（view），所以说 url视图层的内存地址还是View里面的as_view里面的view的内存地址
    3.view里面定义了self，这个self是继承APIView的类产生的对象 ，最后调用了self.dispatch  这个dispatch  查找顺序 对象，类产生的对象 父类  去APIView里面查找dispatch，没有再去View找，
    4.在APIView找到了dispatch  这个是核心
    5.他把一系列的参数赋值给刚才创建的对象，并把request重新封装了新的request ，
    6.有一个大的try包住了三大认证和判断请求方法是不是在列表里 ，在的情况利用反射得到APIView类的方法的内存地址  不在执行一个错误方法的内存地址
    7.加括号执行 并return

# 只要继承了APIView，request对象就成了新的request对象
	1.旧的request怎么封装的
	2.request = self.initialize_request(request, *args, **kwargs)
	3.找到了这个方法注意查找顺序
    4.发现return了一个Request（）对象  这个类不在自己这就是导入的 查找发现是导入的
    5.from rest_framework.request import Request
    6.self._request = request  原来的request赋值给 对象._request   因为这个方法就是封装原来的request 目前的request 还是原来的request ，然后并执行了赋值一些属性
    7.为什么新的request和老的request使用起来一模一样？
是因为再Request类中重写了__getattr__方法
#魔术方法
    __getattr__  查找不到属性的时候调用这个方法
    __setattr__  给一个找不到的属性赋值的时候调用这个方法

 def __getattr__(self, attr):
        try:
            #通过反射 去老的request 取出属性或方法
            return getattr(self._request, attr)
        except AttributeError:
            return self.__getattribute__(attr)
        
  # 新的request有什么特性？
	多了一个data属性 request.data  感觉是个数据属性 其实是个方法
	针对post请求的三种编码格式都可以从data属性中取到 urlencoded  formdata json

# django 默认使用MysqlDB链接mysql---》使用pymysql来替换
# MysqlDB python中老牌 *** 作mysql模块----》2.x很多
# pymysql 3.x上 *** 作mysql
# 2.2之前是没问题
import pymysql
pymysql.install_as_MySQLdb()   # 猴子补丁---》动态的替换对象
# djagno 2.2之前 ---》直接替换成pymysql没问题
# 2.2以后，如果要替换--->需要修改django源码

# mysqlClient：用起来跟pymysql一模一样---》基于MysqlDB开了个分支---》继续维护--》兼容2.x和3.x
# pip3 install mysqlclient   不需要加任何东西，直接 *** 作mysql
# 看人品---》有的机器装不上（Linux）

11.drf学习路线

# 前后端开发模式，接口，restful规范，drf快速使用  
# Request对象和APIView的执行流程
# 序列化组件：（重要）
	把qs对象转成json格式字符串：序列化
    把json格式字符串把它存到库中：反序列化
    数据校验
    
# 请求与响应
	-Request对象：属性和方法
    -Response对象：属性和方法
    
# drf的视图组件：(重要)
	-2个视图基类
    -5个视图扩展类
    -9个视图子类
    -视图集
    
# 路由：
	-两个路由类
    -action装饰器
    
# 三大认证（重要）
	-认证：登录和未登录
    -频率：访问频率（ip，用户id限制）
    -权限：不同权限用户的访问权限
    
# 过滤，分页，排序，异常处理
# 自动生成接口文档
# jwt认证---》认证方式---》现在主流---》面试常考
# 后台管理
# rbac的权限控制