DRF小总结
-
1.web应用模式
#分为两种模式 前后端不分离:前端的界面由后端渲染页面或者重定向，也可以说后端控制前端页面的展示，耦合度太高，适用于网页应用 不适用于app端因为app可能只需要返回数据 前后端分离:后端只返回数据，前端负责接受数据 渲染页面，耦合度较低，后端只需要负责写接口，供前端调用数据 -
2.api接口
前后端交互信息的媒介 四个特点: 长得像返回数据的url连接 请求方式：get、post、put、patch、delete 请求参数 json或者xml格式的数据 返回数据 json或者xml格式的数据 -
3.测试接口工具postman
用来测试接口的工具 针对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 二进制数据 -
4.RESTful APIi规范
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 -
5.序列化和反序列化
序列化：我们识别的数据转换成指定的格式（json）发送给他 反序列化：别人发过来的数据（json）格式，转换或者说还原成自己能识别的数据 -
6.Django restformework
他就是django的第三方app 本质是可以快速写接口 他要求django必须是2.2版本以上 -
7.CBV源码
视图函数的类必须继承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.一级一级返回 -
8.apiview源码
先下载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 -
9.Request对象源码
# 只要继承了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 -
10.mysql引入版本问题
# 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的权限控制
