DRF之初识

已于 2023-12-24 19:08:55 修改
阅读量105 收藏
点赞数
文章标签： python django
于 2023-12-24 17:33:35 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_53842456/article/details/135160444
版权

目录

一、序列化和反序列化

【1】序列化

【2】反序列化

【3】小结

二、DRF的安装和快速使用

(1) 安装DRF：

(2) 配置DRF：

(3) 创建序列化器(Serializer)：

(4) 创建视图(View)：

(5) 配置URL路由：

【补充】下载兼容性问题

【补充】JSON可以序列化和反序列化的类型

【补充】回顾CBV执行流程

三、APIView执行流程分析

【总结】

【补充】回顾装饰器

【补充】APIView再回顾

四、Request对象分析

【总结】

一、序列化和反序列化

  • api接口开发，最核心最常见的一个过程就是序列化

【1】序列化

  • 把我们能识别的数据结构(python的字典，列表，对象)转换成其他语言(程序)能识别的数据结构。
  • 例如：
    • 我们在django中获取到的数据默认是模型对象(queryset)
    • 但是模型对象数据无法直接提供给前端或别的平台使用
    • 所以我们需要把数据进行序列化，变成字符串或者json数据，提供给别人。

【2】反序列化

  • 把别人提供的数据转换/还原成我们需要的格式。
  • 例如：
    • 前端js提供过来的json数据
    • 对于python而言就是字符串
    • 我们需要进行反序列化换成模型类对象
    • 这样我们才能把数据保存到数据库中

【3】小结

  • 序列化：
    • drf称为 read(读取数据)
    • 序列化
    • queryset --- > json
    • 返给前端
  • 反序列化：
    • drf称为 write(写入数据)
    • 反序列化
    • 字符串 --- > json
    • 接收前端的数据

二、DRF的安装和快速使用

DRF(Django REST Framework)是一个强大且灵活的开发工具包，用于构建基于Django的Web API。

它提供了许多内置的功能和工具，使得编写高质量的API变得更加容易和高效。

(1) 安装DRF：

使用pip包管理器，在终端中运行以下命令来安装DRF：

pip install djangorestframework

(2) 配置DRF：

在你的Django项目的settings.py文件中，确保将DRF添加到INSTALLED_APPS列表中：

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'app01.apps.App01Config',
    'rest_framework',  # 注册drf
]

(3) 创建序列化器(Serializer)：

序列化器是DRF中一个重要的概念，它将Python对象转换为JSON等可被传输的格式，并可以反序列化接收到的数据。
在你的应用程序中创建一个名为serializers.py的文件，并定义你的序列化器类。
一个示例：

from rest_framework import serializers
 
class MyModelSerializer(serializers.ModelSerializer):
    class Meta:
        model = MyModel
        fields = '__all__'

在这个示例中，我们使用ModelSerializer来自动创建序列化器类。

(4) 创建视图(View)：

在你的应用程序中创建一个名为views.py的文件，并定义视图类。
一个示例：

from rest_framework import generics
from .serializers import MyModelSerializer
from .models import MyModel
 
class MyModelListView(generics.ListCreateAPIView):
    queryset = MyModel.objects.all()
    serializer_class = MyModelSerializer

在这个示例中，我们使用ListCreateAPIView来创建一个支持列表和创建操作的通用视图。

(5) 配置URL路由：

在你的应用程序的urls.py文件中，定义DRF的URL路由。
一个示例：

from django.urls import path
from .views import MyModelListView
 
urlpatterns = [
    path('mymodels/', MyModelListView.as_view(), name='mymodel-list'),
]

通过上述配置，当访问/mymodels/时，将会调用MyModelListView视图。

  • 以上是使用DRF进行快速开发的简要步骤。
  • 当然，DRF还提供了许多其他功能，如认证、权限控制、过滤器、分页等，可以根据自己的需求进一步学习和定制。
  • 也可以参考官方文档以获得更详细的信息：

【补充】下载兼容性问题

  • 安装命令
pip install djangorestframework
  • 如果你是django2
    • 直接这样装，装最新drf，他们不匹配
    • ---> pip会自动把django卸载，安装最新django，安装最新drf
  • django3 ，这样没有任何问题
  • 强制更新 
    • pip3 install djangorestframework --upgrade

【补充】JSON可以序列化和反序列化的类型

【补充】回顾CBV执行流程

1 请求来了---> 执行 ---> views.BookView.as_view()(request) ---> 执行View类中as_view类方法中的闭包函数view

@classonlymethod
def as_view(cls, **initkwargs):
     def view(request, *args, **kwargs):
        self = cls(**initkwargs) # BookView类实例化得到对象
        self.dispatch(request, *args, **kwargs) # BookView类的dispatch

2 BookView类的dispatch没有 --> View的dispatch

通过反射去self【BookView的对象】中找到 跟请求方式同名的方法  get --> get方法

def dispatch(self, request, *args, **kwargs):
    if request.method.lower() in self.http_method_names:
        handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
    else:
        handler = self.http_method_not_allowed
    return handler(request, *args, **kwargs) # 真正的执行视图类中跟请求方式同名的方法

3 以什么请求方式访问 ---> 就会执行视图类中 跟请求方式同名的方法

比如：http://127.0.0.1:8000/books/  get请求

执行BookView类中get方法

三、APIView执行流程分析

1 在路由中：path('books/', views.BookView.as_view()),请求来了

2 先看 as_view()---->APIView的 as_view---> as_view执行结果跟之前一样，去除了csrf认证

@classmethod
def as_view(cls, **initkwargs):
    view = super().as_view(**initkwargs) # 调用父类的 as_view，view还是View的as_view
    # 以后所有请求，都不会做csrf认证了
    return csrf_exempt(view)

3 请求来了执行 views.BookView.as_view()(request)--->view(request)--->csrf_exempt(view)(request)---> 内部核心 ---> return self.dispatch(request)

4 self 是 APIView类的对象 ---> APIView没有dispatch ---> APIView的dispatch，核心代码如下

def dispatch(self, request, *args, **kwargs):
    # 后续的request都是 initialize_request 返回结果--> 新的request--> drf的Requet类的对象
    request = self.initialize_request(request, *args, **kwargs)
    # 新的request放到了 self.request中---> self是BookView类的对象
    # 后续视图类的方法中 可以直接 self.request取出 当次请求的request对象
    self.request = request

    try:
        # 执行了三大认证：
        '''
        self.perform_authentication(request)
        self.check_permissions(request)
        self.check_throttles(request)
        '''
        self.initial(request, *args, **kwargs)
        ###### 通过反射，去视图类中：BookView中执行跟请求方式同名的方法 ###### 
        if request.method.lower() in self.http_method_names:
            handler = getattr(self, request.method.lower(),self.http_method_not_allowed)
        else:
            handler = self.http_method_not_allowed
        # request是新的Request类的对象了  get方法的第一个参数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

5 看self.initialize_request 是APIView的

def initialize_request(self, request, *args, **kwargs):
    # 类实例化得到对象，传入一些参数
    # Request类--> drf提供的类
    from rest_framework.request import Request
    return Request(
        request,
        parsers=self.get_parsers(),
        authenticators=self.get_authenticators(),
        negotiator=self.get_content_negotiator(),
        parser_context=parser_context
    )

只要继承APIView，以后方法中得request都变了，成了 rest_framework.request.Request 的对象了但是用起来，跟之前的一模一样。

原来的是：django.core.handlers.wsgi.WSGIRequest 类的对象。

【总结】

  1. 以后视图类方法中得request对象，变成了新的request，它rest_framework.request.Request 的对象了，但是用起来跟之前一样
  2. 把新的request对象，同时放到了 视图类的对象中  self.request = request  后续从视图类中可以直接通过 self.request取出来
  3. 在执行视图类的方法之前，执行了三大认证
  4. 如果三大认证或视图类的方法执行出错，会有全局异常处理
  5. 以后所有的接口都去除了csrf认证

【补充】回顾装饰器

装饰器作用：在不改变原函数源代码和调用方式的基础上，为他增加新功能

import time


def add(a, b):
    time.sleep(1)
    return a + b


# 统计add的运行时间
# start_time = time.time()
# add(3, 4)
# end_time = time.time()
# print('运行时间是：', end_time - start_time)


# 写一个通用的，以后只要统计任意函数运行时间，都使用通用的--->改变了调用方式，不行
# def outer(func):
#     start_time = time.time()
#     func(3, 4)
#     end_time = time.time()
#     print('运行时间是：', end_time - start_time)
#
# outer(add)

def outer(func):
    def inner(*args, **kwargs):
        start_time = time.time()
        res = func(*args, **kwargs)
        end_time = time.time()
        print('运行时间是：', end_time - start_time)
        return res

    return inner


# inner=outer(add)
# 调用inner，就是执行，inner内部包了 add函数，inner叫闭包函数
# inner() # 改变了调用方式

# 继续优化
add = outer(add)

res = add(3, 4)  # add现在本质调用 inner，参数传给 inner,inner要能接收a，b 并且有返回结果
print(res)


# 以后想装饰哪个函数 得按如下操作，麻烦
# def ee():
#     print('ee')
#
# ee=outer(ee)
# ee()

# python提供了一个语法糖 @ ，以后只要按如下方式编写代码，就能实现上述功能
@outer  # 等同于  ee=outer(ee)   该语法糖会把被装饰器的函数ee,当做参数，传入outer，并且把outer的执行结果，返回赋值给ee
def ee():
    print('ee')


# 以后ee其实已经不是ee了，是inner了，执行ee本质在执行inner

#####上述是原理####
# 总结，以后写他
def outer(func):
    def inner(*args, **kwargs):
        # 被装饰器函数，执行之前干事
        res = func(*args, **kwargs)
        # 被装饰函数，执行之后干事情
        return res
    return inner

# 装饰某个函数
@outer
def add(a,b):
    time.sleep(1)
    return a+b

【补充】APIView再回顾

在执行视图类的方法之前干了一些事

  • 去除csrf
  • 包装新的requet
  • 在视图类中加入了 self.request
  • 执行三大认证

在执行视图类的方法之后干了一些事

  • 处理全局异常

本质就是做了装饰器的功能

四、Request对象分析

1 分析APIVIew时，分析出，以后request都是新的request了，是drf提供的Request的对象

from rest_framework.request import Request

2 源码解析之 __init__---> 老的request在新的内部---> request._request：

        先看 __init__--->类实例化得到对象时，对对象进行初始化，往对象中放数据

def __init__(self, request, parsers=None, authenticators=None,negotiator=None, parser_context=None):
    # 传入的request是老的，django原生的request
    # 放到了self._request,self 是新的request类的对象
    self._request = request
    self._data = Empty
    self._files = Empty
    # 什么时候调用的 __init__？
        新的                        老的
        -request = self.initialize_request(request, *args, **kwargs)
                老的
            return Request(request)

以后用新的跟用老的一样,为什么？

  • 新的   requet.method
  • 新的   request.path

【补充】魔法方法：

在类内部，以 __开头  __结尾的方法， 在某种情况下会自动调用，他们称之为魔法方法

学过：__init__:  类名() 自动触发
          __str__:   print(对象)  自动触发

还有哪些？ 很多---> 所有类都继承object类---> 它都在object类中

今天要学的 __getattr__ 

        -对象.属性 ，属性不存在会触发     
3 回头看 新的 requet.method用的时候，如果method不存在就会触发 Request类的 __getattr__

源码解析之 __getattr__

# 逻辑肯定是：从老的request中取出，你想要的东西
def __getattr__(self, attr):
    try:
        # 通过反射，去老的中取，能取到就返回，取不到，执行except代码，再取不到就报错
        return getattr(self._request, attr)
    except AttributeError:
        return self.__getattribute__(attr)

4 以后新的request中多了个属性 data ---> 前端post，put提交的请求体中得数据，都会放在request.data中，无论何种编码格式，它都是字典

【总结】

1 老的request还在新的request内部  request._request

2 新的用起来跟老的一样：原因是---> 重写了魔法方法  __getattr__ 
    对象.属性 ---> 属性不存在会触发 __getattr__的执行---> 内部通过反射找到老的request中对应的属性
    request.POST
    request.GET
    request.method
    ....     
3 request.data 多了这个属性，以后无论何种编码，无论何种请求方式 --> 都能取出请求体携带的数据

  • post，put，get ---> 只要放在body体中 ---> 都能取出来 --> 当字典用
  • 如果是urlencoded，form-data编码：OrderedDict --> 原来的request.POST 对象
  • 如果是json编码：dict

4 如果form-data编码---> 取数据：request.data  ---> 取文件：request.FILES中取

5 请求地址栏中参数--> 从request.GET中取 ---> 以后还可以从：request.query_params 中取

  • query_params：查询参数
  • 请求地址中带查询参数---》query_params
ζ浅安时光
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值