首页 > 编程语言 >drf快速使用 CBV源码分析 drf之APIView分析 drf之Request对象分析

drf快速使用 CBV源码分析 drf之APIView分析 drf之Request对象分析

时间:2023-01-18 22:34:15浏览次数:73  
标签:分析 APIView self request 视图 --- 源码 view drf

 

目录

 

序列化和反序列化

api接口开发,最核心最常见的一个过程就是序列化,所谓序列化就是把数据转换格式,序列化可以分两个阶段:序列化、反序列化

序列化:把我们语言识别的数据转换成指定的格式提供给别人。

 
字典,列表,对象  --->  json/xml/prop,massagepack ---> 将json格式的数据提供给别人(前端或其他服务)

'''
序列化和反序列化的格式不仅仅用json格式。
json格式的可读性太高,安全性不足。可以采用prop、massagepack格式等。
'''
PYTHON 复制 全屏

反序列化:把别人提供的数据转换/还原成我们需要的格式。

 

我们在django中获取到的数据默认是模型对象(qreryset对象),但是模型对象数据无法直接提供给前端或别的平台使用,所以我们需要把数据进行序列化,变成字符串或者json数据,提供给别人,这个转换过程称为 ---> '序列化过程'

前端传入到后台的数据 ---> json格式字符串 ---> 后端将数据存到数据库中,需要将数据转成python中的对象 ---> 把json格式字符串转成python对象存到数据库的过程称为 ---> '反序列化'

drf介绍和安装

使用原生django写接口

原生django,不使用任何其他模块,也可以写出符合resful规范的接口,就是写起来麻烦一些。

 
# 查询所有图书
  地址:127.0.0.1:8080/books
  路由:path('/books',views.books)
  视图函数中:
      1. 通过orm查出所有图书对象(qreryset)
      2. 序列化(for循环取出数据自己拼成列表套字典):
		[{name:西游记,price:99},{name:红楼梦,price:99}]
      3. JsonResponse返回给前端

django DRF安装

 
# 定义
drf是django的一个app。

# 作用
帮助程序员快速在django上写符合restful规范的接口

# 安装:
	pip install djangorestframework
   
# 安装的注意事项:
  1.django的最新版本当前为 4.x , 一般我们将django升级到 3.x 或者 2.x
  2.drf的最新版本最低支持django 2.2及以上; 
'''
如果你的版本低于2.2:
	当你安装最新版drf的时候, 会把你老版本的django卸载,给你装上最新版,导致原来的django项目出现问题,运行不了
'''

# 建议:
  django 2.2 以下版本  --->  使用低版本的drf
  django 3.x          --->  使用最新版本的drf
 

django与python对应关系:

 
Python(3.5、3.6、3.7、3.8、3.9)
Django(2.0、2.2、3.0、3.1)
Django中2.X用的多;3.X支持异步,但是并不好,有人用3.X还是在写同步代码

如果django安装的是2.0版本,建议安装以下版本,
pip install djangorestframework==3.10.0

drf快速使用

 
# 针对于一个表,通常需要写哪些接口?
通常需要写5个接口,以后看到的所有接口都是这5个接口的变形。


# 五个基本接口:
  '需求名'      '请求方式'            '访问的路由'
  -查询所有  --->  get    ->  http://127.0.0.1:8000/books/
  -查询一个  --->  get    ->  http://127.0.0.1:8000/books/1/
  -新增一个  --->  post   ->  http://127.0.0.1:8000/books/ 
                             请求体body中携带新增的数据
        
  -修改      --->  put,patch
				 (实际编码中,基本都用put)
  	                     ->  http://127.0.0.1:8000/books/1/ 
                             请求体body中传入修改的数据
        
  -删除一个  --->  delete -> http://127.0.0.1:8000/books/1/
  
# 注册、登录接口的本质:  
登陆接口 ---> 本质其实是查询一个
注册接口 ---> 本质是新增一个

# postman测试接口的特点:
postman的接口测试是严格的,对于一个路由地址,斜杠有和没有是有区别的。
postman不会像浏览器一样,自动补全斜杠再请求一次。

模型

在模型层创建一个简单的只有3个字段的图书类。

 
class Book(models.Model):
    name = models.CharField(max_length=32)
    price = models.DecimalField(decimal_places=2, max_digits=5)
    author = models.CharField(max_length=32)

序列化类

新建一个py文件编写序列化类BookSerializer。

 
from .models import Book
from rest_framework import serializers

class BookSerializer(serializers.ModelSerializer):
    class Meta:
        model = Book
        fields = '__all__'

视图

在视图层使用相对导入,导入刚刚创建的图书类。(也可以使用绝对导入,但是推荐使用相对导入)
导入ModelViewSet模块,自己写一个类继承这个模块。
类中属性serializer_class使用我们刚刚创建的序列化类。

 
from rest_framework.viewsets import ModelViewSet
from .models import Book # 模块导入推荐使用相对导入
# from app01.models import Book # 使用绝对导入
from .serializer import BookSerializer
class BookView(ModelViewSet):
    queryset = Book.objects.all()
    serializer_class = BookSerializer

路由

 
from rest_framework.routers import SimpleRouter
from app01 import views

router = SimpleRouter()
router.register('books', views.BookView, 'books')
urlpatterns = [
    path('admin/', admin.site.urls),
]
urlpatterns += router.urls

datagrip

pycharm是java写的 django链接数据库需要java链接数据库的驱动

类似navicat。datagrip是pycharm公司写的链接数据的软件。

使用postman测试接口

使用get请求获取所有图书:

使用put请求修改图书:

使用patch请求修改图书:

可以只局部修改一部分。

CBV源码分析

 
1. cbv路由写法:
path('test/', views.TestView.as_view())
2. path的第二个参数实际是函数内存地址
3. as_view()执行完,实际是闭包函数view的内存地址
4. 当请求来了,路由匹配成功,会执行view(request),传入当次请求的request对象
5. view函数的返回值:return self.dispatch(request, *args, **kwargs)
6. View类中找dispatch
7. 如果是get请求就会执行视图类中的get方法,如果是post请求,就会执行视图类的post方法


# as_view 类的绑定方法--->View类的方法-->@classonlymethod
# dispatch核心代码--->getattr反射--->从当前对象(视图类的对象)--->如果是get请求-->会拿到get方法--->handler就是get方法--->handler(request)本质就是--->get(request)
handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
return handler(request, *args, **kwargs)

# 通过描述符自己写装饰器来装饰类---》完成类似于property,classmethod。

查看源码推荐pycharm配置:

打开这个show Members,可以查看py文件里面的变量名。

classonlymethod:
classonlymethod继承于classmethod.
相当于django开发人员自定义的classmethod。

推荐阅读:
python面向对象高阶-描述符

drf之APIView分析

View类的导入方式

以后使用drf写接口,在视图层都是写视图类
drf最顶层的视图类是APIView,是drf中所有视图类的父类。
APIView又继承了django中的View类:

这个View是这样导入的:
from django.view.genenic import View

不对呀,我们之前写视图类,是这样导入的:
from django import view
然后我们的类继承 view.View

为什么这两种方式都会导入同一个View类?

不论是genenic还是view都是包名。
在包内的__init__文件注册View类就可以实现导入了。

 
# View类真实路径
from django.views.generic.base import View 
# 因为在generic包的init里注册了
from django.views.generic import View 
# 因为在views包的init里注册了
from django.views import View       

继承了django View类的类,就是视图类。
所以继承APIView的类,也是视图类。

路由层写法和以前一样:

这里如果路由冲突了,会怎么样?(有两个视图类对应test/路由)
这里底层是for循环,将列表中的路由一个一个取出匹配,如果上面的匹配成功,for循环就break退出,不会继续匹配,所以下面这个视图类永远都不会执行。

APIView的执行流程

 
# APIView的执行流程
路由 path('order/', views.OrderView.as_view())---》第二个参数是函数内存地址---》APIView的as_view的执行结果---》本质还是用了View类的as_view内的view闭包函数,去掉了csrf认证----》当请求来了---》触发view闭包函数执行,并且传入request--->调用了self.dispatch-->self是视图类的对象,从OrderView中找dispatch,但是找不到----》父类APIView中有---》本质执行是APIView的dispatch----》

APIView的as_view方法

 
# APIView的as_view方法
  view = super().as_view(**initkwargs) # 调用APIView的父类(View)的as_view方法
  return csrf_exempt(view) # 去掉csrf_exempt的认证,以后只要继承了APIView后,csrf就无效了,无论中间件是否注释掉


# crsf的局部禁用--》在视图函数上加装饰器---》csrf_exempt装饰器---》装饰器本质就是一个函数
@csrf_exempt       # 装饰器的@ 是一个语法糖(特殊语法)-->把下面的函数当参数传入装饰器中并且把返回结果赋值给函数名:index=csrf_exempt(index)
def index(request)
	pass
跟 csrf_exempt(index) 一毛一样

路由 path('order/', views.OrderView.as_view()):

path第二个参数是函数内存地址:
我们自己的视图类OrderView里面没有as_view方法,所以回去父类APIView找as_view方法,
由于APIView里面有as_view,所以不会去APIView的父类View找。

APIView里的as_view:

重要的两行代码:

 
view = super().as_view(**initkwargs) # 调用APIView的父类(View)的as_view方法

return csrf_exempt(view) # 去掉csrf_exempt的认证,以后只要继承了APIView后,csrf就无效了,无论中间件是否注释掉

父类(View)的as_view方法最终会拿到 ---> 我们自己编写的视图类中的方法 :

如果来了一个get请求 dispatch方法会通过反射从我们视图类产生的对象中获取方法:

如何理解这行代码return csrf_exempt(view)

 
@csrf_exempt
def index(request):
    pass
跟 csrf_exempt(index) 一模一样

# 因为装饰器的本质是:
index = csrf_exempt(index)

CBV本质上就是FBV。
发送请求到后端实际上就是执行了我们视图类中的一个函数。
如果视图层有一个视图函数:

 
def index(request):
    return Httpresponse('你好')

正常情况下,我们给FBV添加装饰器语法糖实际上是执行了:index = csrf_exempt(index)

 
@csrf_exempt
def index(request):
    return Httpresponse('你好')

当路由匹配成功时,看起来是执行index函数,实际是执行crsf_exempt(index)
FBV路由层看起来是这样子:
path('index/', views.index)
实际是:
path('index/', csrf_exempt(index))
CBV路由层看起来是这样子:
path('index/', views.TestView.as_view())
实际是:
path('index/', crsf_exempt(View))
这个View最终是我们视图类中的一个方法的函数地址(通过反射拿到的)

总结:APIView的as_view的作用只是给你自己写的视图类加了个crsf_exempt装饰器(去掉了crsf认证)

APIView的dispatch方法

 
# APIView的dispatch
  def dispatch(self, request, *args, **kwargs):
    	# request是新的drf提供的request,它是由老的django的request得到的
      	# 通过老request,生成一个新request,drf的Request的对象
        request = self.initialize_request(request, *args, **kwargs)
        # 把新的request,放到了我们自己的视图类对象中
        self.request = request
        try:
           # 执行了三大认证(认证,权限,频率)
            self.initial(request, *args, **kwargs)
            # self.http_method_names是个列表
            if request.method.lower() in self.http_method_names:
              	# 原来dispatch的核心代码
                handler = getattr(self, request.method.lower(),
                                  self.http_method_not_allowed)  # 通过反射获取我们视图类中的方法
            else:
                handler = self.http_method_not_allowed
            # 这里也是原来dispatch写的代码,但是request已经不是老request了,是上面生成的新request
            response = handler(request, *args, **kwargs) # 执行视图函数的方法
        except Exception as exc:
          	# 无论在三大认证过程中还是执行视图函数方法过程中,只要抛了异常,都会被捕获到
            # 处理全局异常
            response = self.handle_exception(exc)

        self.response = self.finalize_response(request, response, *args, **kwargs)
        return self.response

# dispatch方法总结
请求来了之后,dispatch方法,先处理request产生新的request对象,将这个新的request对象放入我们自己视图类产生的对象中。
再进行三大认证,认证完了之后获取我们类中的方法并执行,最后dispatch方法返回一个返回值。

# APIView执行流程
  1 包装了新的Request对象,以后视图类中的方法中传入的request对象都是新的
  2 在进入视图函数之前,执行了三大认证
  3 无论三大认证还是视图函数的方法,执行过程中出了异常,都会被处理掉

把新的request,放到了我们自己的视图类对象中:

http_method_names列表:

列表里面放了八大请求方法。

drf之Request对象分析

如何包装的新的request

initialize_request方法如何将django产生的老request包装成新的request?

 
#  如何包装的新的request
request = self.initialize_request(request, *args, **kwargs)---》由于我们的对象里没有initialize_request方法,所以去APIView找initialize_request方法---》核心代码

# initialize_request方法核心代码
from rest_framework.request import Request  # 导入drf新Request类
return Request(
            request,  # 老的request
            parsers=self.get_parsers(),
            authenticators=self.get_authenticators(),
            negotiator=self.get_content_negotiator(),
            parser_context=parser_context
        )
新的Request类中的__init__方法有如下代码:
self._request = request ---》新的request._request是老的request

新的:<class 'rest_framework.request.Request'>
老的:<class 'django.core.handlers.wsgi.WSGIRequest'>

APIView中的initialize_request方法:

drf 新Request类:

Request类__init__:

在我们写的视图类中查看老的request:

执行get方法里面的代码之前,我们的request已经被换成了新的request。get函数里面的request是drf产生的新request。
更多示例:

request._requestself.request._request存放的都是django产生的老request。

查看request的类型:

三大认证执行顺序

 
# 三大认证是如何走的
self.initial(request, *args, **kwargs)---》APIView的
核心代码:
   self.perform_authentication(request)  # 认证
   self.check_permissions(request)   #权限
   self.check_throttles(request) # 频率

# 三大认证执行顺序
认证  --->  权限  --->  频率

# 总结
'''
路由匹配成功   ---三大认证--->   执行视图类中方法

三大认证有点类似于中间件: 

请求到达后端服务器   ---中间件--->   路由匹配
'''

新Request常用属性和方法

request.data

 
# rest_framework.request.Request --->常用属性和方法

#  request.data定义
新的request有一个data方法(此方法被伪装成属性),前端post请求传入的数据都在equest.data里面。

# 与老的request.POST的区别
request.POST:
只能处理urlencoded和formdata编码格式。
request.data:
无论前端用什么编码格式的post提交的数据,都可以从request.data中获取。

未改变的方法

新的request也有一些方法和老request使用方式相同:

 

request.files # 新的request.files也是获取上传的文件对象

以后直接使用新的request.method  request.path 拿到的就是老的request.method...  # 跟之前用法相同

使用getattr调用老的request的方法

如何使用新request调用老request中的方法:

 
# 原理
对象.调用属性或方法会触发 魔法方法 __getattr__
原因在于新的request类重写了__getattr__,以后新的request.method用的时候本质就是request._request.method


# 代码
1.使用新的request方法 ---> 执行request.method

2.当新request类中没有method这个名字时,触发新request类中的__getattr__方法

  def __getattr__(self, attr):  # 传入字符串'method'
       try:
            return getattr(self._request, attr)  # 通过反射去老的里面取 self._request存的是老的request
        except AttributeError:
            return self.__getattribute__(attr)
        
3. 新的request.method用的时候本质就是:
	request._request.method
           
          
# 总结:新的request当老的用即可,只是多了个data属性,存放前端post请求传入的数据,三种编码格式都可以存放在data中。

新的request.data和老的request.POST的区别:

发送formdata编码格式:

发送json编码格式:

标签:分析,APIView,self,request,视图,---,源码,view,drf
From: https://www.cnblogs.com/xiao-fu-zi/p/17060771.html

相关文章

  • 浅谈Zookeeper集群选举Leader节点源码
    写在前面:zookeeper源码比较复杂,本文讲解的重点为各个zookeeper服务节点之间的state选举。至于各个节点之间的数据同步,不在文本的侧重讲解范围内。在没有对zookeeper组件有一......
  • 简单分析Tomcat中WebappClassLoader的loadClass方法
    tomcat自定义在Java的双亲委派机制的基础上进行了修改。甚至于为了各个服务直接相互隔离,直接打破了双亲委派机制。那么什么叫打破双亲委派机制呢?我们都知道tomcat是一个容......
  • 浅谈Redis基本数据类型底层编码(含C源码)
    文章目录​​一、String​​​​1、int​​​​2、embstr​​​​3、raw​​​​4、bitmap​​​​5、hyperloglog​​​​二、List​​​​1、ziplist​​​​2、quicklist......
  • STM32 PLC底层源码 FX2N源码 断电保持/Keil源码
    STM32PLC底层源码FX2N源码断电保持/Keil源码三菱指令编码注释较多,适合初学者,发编译环境:KeilMDK4.7以上的版本,CPU需要:STM32F103--RAM内存不小64K,Flash程序空间不小于256......
  • JS 前端大文件上传源码
    ​对于大文件的处理,无论是用户端还是服务端,如果一次性进行读取发送、接收都是不可取,很容易导致内存问题。所以对于大文件上传,采用切块分段上传,从上传的效率来看,利用多线程......
  • Java反序列化-URLDNS利用链分析
    前言URLDNS链是Java反序列化中比较简单的一个链子,由于URLDNS不依赖第三方包和不限制jdk版本,所以经常用于检测反序列化漏洞。URLDNS并不能执行命令,只能发送DNS请求。(应该......
  • #Powerbi 利用时间智能函数,进行周度分析
    在实际工作中,我们往往需要同比分析,月度和年度的分析都有对应的时间智能函数,分别是MTD和YTD,但是缺少了周度的时间智能函数,而恰恰日常工作中,我们又需要以周度来进行对应的分......
  • JDK 1.8 TreeMap源码分析
    /**   *TreeMap特点:   * 底层:二叉红黑树key输入无序,升序排列,null不可以   * 1.2    */publicclassTreeMap<K,V>   extendsAbstractMap<K......
  • JDK 1.8 Hashtable的源码分析
       /**   *Hashtable特点:   * 与hashTable一样1.1效率低,线程安全,key不为null hashMap1.2 效率高,key为null长度11    */publicclassHashta......
  • JDK 1.8 HashMap的源码分析
       /**   *HashMap的特点:   *1.AbstractMapMap冗余   *2.与hashTable一样1.1效率低,线程安全,key不为null hashMap1.2 效率高,key为null ......