DRF的序列化和反序列化
目录
- DRF的序列化和反序列化
- Django传统序列化
- Django传统反序列化
- 安装DRF
- 序列化器serializers
- 序列化
- 反序列化
- 反序列化保存
- instance和data
- CBV和APIView执行流程源码解析
- CBV源码分析
- APIView源码分析
- DRF的Request解析
- 魔法方法`__getattr__`
什么是序列化?
把我们能识别的对象,转换成别的格式,提供给其他人
- 从数据库取出来—》序列化–》 给前端
什么是反序列化?
将别人提供给我们的编码数据转换为我们需要的数据
- 前端数据发送给接口—》反序列化—》转存数据库
Django传统序列化
以Django框架为例:
def get(self, request):response = {'code': '200', 'msg': "查询成功", 'results': results}response = json.dumps(response)return JsonResponse(response, safe=False)
接收到get请求后将python字典序列化为json格式响应回去
Django传统反序列化
在Django中反序列化需要根据参数的编码类型使用不同方法
json.loads(request.POST)
在Django中并不能转换url
编码类型,因此当参数为url
编码时这种写法是错误的
反序列化json数据:
# json数据:b'{"abc":"def"}'data = json.loads(request.body)
# 结果:{'abc': 'def'}data = json.loads(request.POST)
# 报错data = request.POST
# 为空 <QueryDict: {}>
encoded数据:
数据:
def put(self, request, u_id):print(request.body)# b'abc=def&qqq=www'print(f'POST:{request.POST}')# POST:<QueryDict: {}>print(f'body:{request.body}')# body:b'abc=def&qqq=www'
可以看出在没有第三方模块的情况下无法将request中的参数转化为有效数组,因此接下来我们需要借助Django的DRF(Django Rest Framework)框架
安装DRF
pip install djangorestframework
序列化器serializers
序列化
原代码
class task(View):# 获取所有内容def get(self, request):results = []task_list = (models.task.objects.all())[results.append({'task_id': i.task_id, 'task_name': i.task_name, 'task_time': str(i.task_time),'task_desc': i.task_desc}) for i in task_list]response = {'code': '200', 'msg': "查询成功", 'results': results}response = json.dumps(response)return JsonResponse(response, safe=False)
添加serializers.py(自行在app中创建)
# taskserializer.py
from rest_framework import serializersclass TaskSerailizer(serializers.Serializer):# 过滤条件 下面是会被带入参数的字段task_id = serializers.CharField()task_name = serializers.CharField()task_time = serializers.CharField()task_desc = serializers.CharField()
视图
from rest_framework.views import APIView
from rest_framework.response import Responseclass task(APIView):# 获取所有def get(self, request):# 获取表中所有对象task_obj = models.task.objects.all()# 将task_obj丢进序列化器序列化serializer = TaskSerailizer(instance=task_obj, many=True)return Response({'code': '200', 'msg': '查询成功', 'result': serializer.data})
serializer = TaskSerailizer(instance=task_obj, many=True)
instance
:指定要被序列化的对象
many
:表示要对多个对象序列化
查询成功
反序列化
from rest_framework import serializers
from rest_framework.exceptions import ValidationErrorclass TaskSerailizer(serializers.Serializer):task_id = serializers.CharField()task_name = serializers.CharField(max_length=10)task_time = serializers.CharField()task_desc = serializers.CharField(min_length=10)def validate_task_name(self, task_name):if 'qqq' in task_name:raise ValidationError('task_name中不能包含qqq')else:return task_namedef validate(self, attrs):# attrs是前端传入且经过validate_name校验的参数if attrs.get('task_name') == attrs.get('task_desc'):raise ValidationError('task名和task描述不能相同')else:return attrs
validate_task_name
:自定义的钩子函数,当task_name出现qqq时返回报错信息
validate
:serializers
已经写好的钩子函数,attrs是前端传入且经过validate_task_name
校验的参数不符合max_length时会使用
DRF
自带的报错提示
反序列化保存
需要在自定义的serializers.py文件中重写create和update方法
from rest_framework import serializers
from app import modelsclass TaskSerailizer(serializers.Serializer):task_id = serializers.CharField()task_name = serializers.CharField(max_length=10)task_time = serializers.CharField()task_desc = serializers.CharField(min_length=10)def create(self, validated_data):# validated_data:前端传入且已通过校验的数据models.task.objects.create(**validated_data)def update(self, instance, validated_data):# instance:要更新的已存在对象# validated_data:前端传入且已通过校验的数据instance.task_id = validated_data.get('task_id')instance.task_name = validated_data.get('task_name')instance.task_time = validated_data.get('task_time')instance.task_desc = validated_data.get('task_desc')instance.save()return instance
views.py
instance
:要更新的已存在对象
validated_data
:前端传入且已通过校验的数据
def put(self, request, u_id):task_obj = models.task.objects.filter(pk=u_id).first()# 改对象必须传data和instanceserializer = TaskSerailizer(instance=task_obj, data=request.data)if serializer.is_valid():serializer.save()return Response({'code': '200', 'msg': "修改成功", 'result': serializer.data})else:return Response({'code': '201', 'msg': serializer.errors})
instance和data
instance
:序列化后需要被响应回去的字段,在创建(create)和更新(update)对象时,会将这个对象序列化为 JSON 数据返回给前端
data
:前端传入的需要被反序列化的数据。这些数据经过反序列化处理后,会被用于创建或更新对象实例。
CBV和APIView执行流程源码解析
CBV源码分析
在进入APIView之前首先需要了解传统CBV的原理
例:
# urls.py
from django.contrib import admin
from django.urls import path
import app.viewsurlpatterns = [path('admin/', admin.site.urls),path('app/', app.views.task.as_view()),
]
# views.py
class task(View):# 根据id获取def get(self, request, u_id):response = {'code': '200', 'msg': "查询成功"}return JsonResponse(json.dumps(response), safe=False)
首先引入问题:为什么浏览器向后端发送get请求时会被该get方法精准接受?
其实是因为在注册url时app.views调用的as_view()方法帮我们做好了大部分规划
Ctrl+左键进入as_view()源码
class View:http_method_names = ["get","post","put","patch","delete","head","options","trace",]def __init__(self, **kwargs):for key, value in kwargs.items():setattr(self, key, value)@classonlymethoddef as_view(cls, **initkwargs):"""Main entry point for a request-response process."""for key in initkwargs:if key in cls.http_method_names:raise TypeError("The method name %s is not accepted as a keyword argument ""to %s()." % (key, cls.__name__))if not hasattr(cls, key):raise TypeError("%s() received an invalid keyword %r. as_view ""only accepts arguments that are already ""attributes of the class." % (cls.__name__, key))def view(request, *args, **kwargs):self = cls(**initkwargs)self.setup(request, *args, **kwargs)if not hasattr(self, "request"):raise AttributeError("%s instance has no 'request' attribute. Did you override ""setup() and forget to call super()?" % cls.__name__)return self.dispatch(request, *args, **kwargs)view.view_class = clsview.view_initkwargs = initkwargs# __name__ and __qualname__ are intentionally left unchanged as# view_class should be used to robustly determine the name of the view# instead.view.__doc__ = cls.__doc__view.__module__ = cls.__module__view.__annotations__ = cls.dispatch.__annotations__# Copy possible attributes set by decorators, e.g. @csrf_exempt, from# the dispatch method.view.__dict__.update(cls.dispatch.__dict__)# Mark the callback if the view class is async.if cls.view_is_async:markcoroutinefunction(view)return viewdef dispatch(self, request, *args, **kwargs):# Try to dispatch to the right method; if a method doesn't exist,# defer to the error handler. Also defer to the error handler if the# request method isn't on the approved list.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_allowedreturn handler(request, *args, **kwargs)def http_method_not_allowed(self, request, *args, **kwargs):logger.warning("Method Not Allowed (%s): %s",request.method,request.path,extra={"status_code": 405, "request": request},)response = HttpResponseNotAllowed(self._allowed_methods())if self.view_is_async:async def func():return responsereturn func()else:return response
@classonlymethod
表示只能用类调用此方法,这也是为什么我们只能用as_views()而不是as_views- 这个时候我们来到了task(View)继承的View类下的as_view()方法
- 中间的步骤先不管 直接看
return view
def view(request, *args, **kwargs):self = cls(**initkwargs)self.setup(request, *args, **kwargs)if not hasattr(self, "request"):raise AttributeError("%s instance has no 'request' attribute. Did you override ""setup() and forget to call super()?" % cls.__name__)return self.dispatch(request, *args, **kwargs)
- 这个时候可以看出其实我们就是在调用父类的view方法
- 这里的request参数就是我们的浏览器接受的request请求,如果没填request则会弹出一个error
- 重点是最后调用了实例中的dispatch方法
- 既然我们的task类调用了dispatch方法那么就应该在task类下搜寻这个方法,但是很明显我们没有写过这方法,因此又回到父类View中的dispatch方法(这俩方法挨得很近,往下翻翻就找到了)
def dispatch(self, request, *args, **kwargs):# Try to dispatch to the right method; if a method doesn't exist,# defer to the error handler. Also defer to the error handler if the# request method isn't on the approved list.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_allowedreturn handler(request, *args, **kwargs)
if request.method.lower() in self.http_method_names:
当我们的request请求类型存在于http_method_names
时- 那么先看看这个
http_method_names
是什么东西
http_method_names = ["get","post","put","patch","delete","head","options","trace",
]
- 其实就是个定义好的字符串列表
- 再接着看
dispatch
handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
- 其实就是从我们task实例中获取相应的HTTP请求方法,如果不存在就用它默认的
- 最后返回handler,再解释一下gatter的用法
class Test(object):x = 1a = Test()
print(getattr(a, 'x')) # 获取属性 x 值
# 结果:1
print(getattr(a, 'y', 'None')) # 获取属性 y 值不存在,但设置了默认值
# 结果:None
print(a.x) # 效果等同于上面
# 结果:1
- 回到我们最初的问题
为什么浏览器向后端发送get请求时会被该get方法精准接受?
- 走到这里基本可以得出结论了,说白了就是如果我有get就走我类下的get方法,没有就走它默认的
APIView源码分析
- class task(APIView):直接Ctrl+左键进入APIView
- 直接看里面的as_view()方法
class APIView(View): @classmethoddef as_view(cls, **initkwargs):if isinstance(getattr(cls, 'queryset', None), models.query.QuerySet):def force_evaluation():raise RuntimeError('Do not evaluate the `.queryset` attribute directly, ''as the result will be cached and reused between requests. ''Use `.all()` or call `.get_queryset()` instead.')cls.queryset._fetch_all = force_evaluationview = super().as_view(**initkwargs)view.cls = clsview.initkwargs = initkwargs# Note: session based authentication is explicitly CSRF validated,# all other authentication is CSRF exempt.return csrf_exempt(view)
- 当请求发送过来时先进入csrf_exempt(view)
def csrf_exempt(view_func):"""Mark a view function as being exempt from the CSRF view protection."""# view_func.csrf_exempt = True would also work, but decorators are nicer# if they don't have side effects, so return a new function.@wraps(view_func)def wrapper_view(*args, **kwargs):return view_func(*args, **kwargs)wrapper_view.csrf_exempt = Truereturn wrapper_view
- 里面其实就是第一个CSRF装饰器,它帮你免除了CSRF保护,并返回了一个带有相同功能的函数
view = super().as_view(**initkwargs)
:调用了父类的as_view(),也就是老的View类- 那么既然它既然调用了父类的方法,肯定也会有些地方进行了重新
- 老View中最重要的方法是什么?是dispatch
- 直接在APIView类中找它重写的dispatch
def dispatch(self, request, *args, **kwargs):"""`.dispatch()` is pretty much the same as Django's regular dispatch,but with extra hooks for startup, finalize, and exception handling."""self.args = argsself.kwargs = kwargs# 1.这里包装了新的request对象,此时的request在原Django的request对象的基础上升级了request = self.initialize_request(request, *args, **kwargs)self.request = requestself.headers = self.default_response_headers # deprecate?try:# 2.initial里做了三件事:三大认证:认证,频率,权限self.initial(request, *args, **kwargs)# Get the appropriate handler method# 3.这里看注释也能猜到就是执行了跟请求方式同名的方法,也就是我们用的get post...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_allowedresponse = handler(request, *args, **kwargs)# 4.如果三大认证或者视图函数出现异常会在这里统一处理except Exception as exc:response = self.handle_exception(exc)self.response = self.finalize_response(request, response, *args, **kwargs)return self.response
- 先来看一下三大认证
def initial(self, request, *args, **kwargs):"""Runs anything that needs to occur prior to calling the method handler."""self.format_kwarg = self.get_format_suffix(**kwargs)# Perform content negotiation and store the accepted info on the requestneg = self.perform_content_negotiation(request)request.accepted_renderer, request.accepted_media_type = neg# Determine the API version, if versioning is in use.version, scheme = self.determine_version(request, *args, **kwargs)request.version, request.versioning_scheme = version, scheme# Ensure that the incoming request is permittedself.perform_authentication(request)self.check_permissions(request)self.check_throttles(request)
- self.perform_authentication(request) 验证请求合法性
- self.check_permissions(request) 检查请求权限
- self.check_throttles(request) 验证请求频率
总结:
- 只要执行了DRF的APIView,就不会再有CSRF限制了
- request也会被替换为它新建的request
- 在执行请求方法之前(与方法重名的request请求)进行了三大验证
- 验证合法性
- 验证请求权限
- 验证请求频率
- 三大认证和视图函数中任意位置出现异常统统报错
DRF的Request解析
先从结果出发,DRF的Request比Django的request多了个data属性
就是这个data属性帮我们序列化和反序列化,无需额外针对它的编码和请求方式进行修改判断
而这个新的request对象就是
from rest_framework.request import Request
这里的Request对象
老样子直接进他源码
class Request:
- 此时抛出第一个疑问:既然新Request没有继承老的request那他是怎么实现方法重构的呢?难不成一个一个写吗
- 其实它在下面用到了魔法方法
__getattr__
def __getattr__(self, attr):"""If an attribute does not exist on this instance, then we also attemptto proxy it to the underlying HttpRequest object."""try:_request = self.__getattribute__("_request")return getattr(_request, attr)except AttributeError:return self.__getattribute__(attr)
__getattr__
是一个拦截方法,当调用了类中不存在的属性时就会触发__getattr__
- _
request = self.__getattribute__("_request")
的意思就是通过调用对象的__getattribute__
方法来获取对象中名为_request
的属性值,说白了就是去老request中取属性 - 那么接下来在找找data属性在哪
request.data
直接进入data查看源码
- 注意是rest_framework.request的data
@property
def data(self):if not _hasattr(self, '_full_data'):self._load_data_and_files()return self._full_data
- 当前实例中没有_full_data属性时自动调用_load_data_and_files()方法,而这个方法就是他帮我们封装各种请求和编码方式的地方(内容过多有兴趣自己去了解)
总结:
- 之前如何用request,在DRF中还是如何用
- request.data将请求体的数据,将原先的各个方法包装成了数据属性
- request.query_params就是原先的request.GET,这么写是为了符合restful规范
__getattr__
中的request._request 就是老的Django中的request
魔法方法__getattr__
以__开头的都叫魔法方法,魔法方法不是我们主动调用的,而是在某种情况下自动触发的
__getattr__
用于拦截对象.属性,如果属性不存在则会触发
class Person:def __getattr__(self, item):print('根据:', item, '取值')return '123'p = Person()
print(p.name) # 属性不存在,就会打印__getattr__中的内容
# 根据: name 取值
# 123