DRF序列化器 DRF中有一个serializers模块专门负责数据序列化，DRF提供的方案更先进、更高级别的序列化方案。...在数据校验时候传入这个配置即可捕获异常，异常状态码是400： raise_exception=True 需要修改app的视图函数： myapp/views.py from myapp.models...获取数据 -> 响应返回前端 反序列化（写数据)：视图获取前端提交的数据 -> 数据传入序列化器 -> 调用序列化器的.is_valid方法进行效验 -> 调用序列化器的.save()方法保存数据 序列化器常用方法与属性...： serializer.is_valid()：调用序列化器验证是否通过，传入raise_exception=True可以在验证失败时由DRF响应400异常。...serializer.errors：获取反序列化器验证的错误信息 serializer.data：获取序列化器返回的数据 serializer.save()：将验证通过的数据保存到数据库（ORM操作）
APIView APIView是Django REST framework提供的所有视图的基类，继承自Django的View类。...对象，而不是Django的HttpRequeset对象； 视图方法可以返回Django REST framework的Response对象，视图会为响应数据设置（render）符合前端要求的格式；(需要...不受csrf认证规则的限制，因为由as_view方法完成路由配置，返回配置函数是csrf_exempt(view)。 APIView与View的使用基本相同，像往常一样。...) 关于APIView使用的Django REST framework的Request对象，以及上面使用的Response对象，在DRF的Request对象和Response对象中介绍。...基于函数的视图 有时候，我们并不需要使用类。为此，DRF提供了一组简单的装饰器，用于包装基于函数的视图以确保它们接收DRF的Request对象。
作者&好友：Laoqi 1、请求与响应 1.1 Request（请求） drf 传入视图的request 不再是Django默认的HttpRequest对象，而是drf 提供的拓展了HttpRequest...2.1 两个视图基类 2.1.1 APIView APIView是drf 提供的所有视图的基类，继承自Django的View父类。...APIView与View的不同之处在于： 传入到视图方法中的是REST framework的Request对象，而不是Django的HttpRequeset对象； 视图方法可以返回REST framework...如果序列化器对前端发送的数据验证失败，返回400错误。...成功返回200，序列化器校验数据失败时，返回400错误。
，本文就来介绍DRF在这一部分的技术升级。...400，是不容易阅读的，于是DRF提供了标识符如HTTP_400_BAD_REQUEST来替代。...@api_view和APIView DRF对API视图做了2个封装： @api_view用于函数视图。 APIView用于类视图。...东方说 最近测试开发和业务测试的话题频频出现在TesterHome论坛上，讨论激烈，我觉得从公司的角度来说，只会关注员工的产出有没有给公司带来价值，无论技术多厉害，不能创造价值终究是会优先被裁的。...从个人的角度来说，只会业务测试的出路肯定是会越来越窄的，努力提高技术，辅助业务测试，同时提升效率，才是更好的发展方向。
DRF自动生成OpenAPI文档 API schemas是非常有用的，可以帮助我们生成接口文档以及可与API交互的动态客户端。...在这里我们使用drf-spectacular这个第三方库来自动生成OpenAPI schemas. drf-spectacular 安装，配置步骤可以参考drf-spectacular文档，下面简单的给出步骤...return Response({'msg': '保存失败'}, status=400) 对于HTTP Body中的内容，都在序列化器中描述了，但是对于URL参数，是默认没有描述的...drf-spectacular自动生成文档，很大程度上依赖于文档字符串以及queryset和serializer_class（DRF的APIView没有这两个属性，对于APIView自动生成文档有困难，...当然你可以直接在APIView中定义这两个属性，但是会显得很奇怪。）
400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作，该操作是幂等的。...API key" } 返回结果，针对不同操作，服务器向用户返回的结果应该符合以下规范 GET /collection：返回资源对象的列表（数组） GET /collection/resource：返回单个资源对象..."" 1) 请求走的是APIView的as_view函数 2) 在APIView的as_view调用父类(django原生)的as_view，还禁用了 csrf 认证 3) 在父类的as_view中...dispatch分发请求走的又是APIView的dispatch 4) 完成任务方法交给视图类的请求函数处理，得到请求的响应结果，返回给前台 """ 请求模块 ---- 源码入口 APIView类的...# 自己视图类的类属性(局部配置) => # APIView类的类属性设置 => # 自己配置文件的DEFAULT_RENDERER_CLASSES(全局配置) => # drf
快速使用DRF写出接口 序列化和反序列化 drf快速使用 views.py serializer.py urls.py 在settings的app中注册 models.py postman测试 CBV源码流程分析...Django View和DRF APIView的小插曲 DRF之APIView和Request对象分析 APIView的执行流程 Request对象分析 原来的django中没有request.data...为2的数据 CBV源码流程分析 因为DRF框架里大部分都是基于CBV(视图类)写，所以流程是什么，如何执行需要了解，同时也方便理解APIView，顺便提一嘴APIView也是继承了View -...多态、组合、反射 Django View和DRF APIView的小插曲 ps：不管是DRF中的APIView还是乱七八糟的xxView，最后只要继承了Django中的View就是视图类 DRF之APIView...和Request对象分析 APIView的执行流程 # 同样和Django中一样写一个视图类，只不过DRF中用APIView底层还是View '''views.py''' from rest_framework.response
DRF官网地址，但是大家记住一句话，即便是没有这drf，我们照样能做前后端分离的项目，自己做规范的数据接口，返回json数据，都是没问题的昂，那为什么还用drf啊，这个更nb。...玩DRF之前，我们先说一下我们DRF中有哪些内容： 咱们玩下面10个组件： a.APIView (*****) b.序列化组件 (*****) c.试图类(mixin) (*****)...组件 在我们的视图中，通过CBV来写视图的时候，继承APIView，url不变，还是上面那个，通过浏览器访问，照样能够看到我们返回的数据， views.py内容如下： from django.shortcuts...,APIView是继承的django的View，也就是APIView在View的基础上添加了一些其他的功能 from rest_framework.views import APIView class...json数据，存放到request.data里面，可以通过postman测试一下看看效果，为什么？
目录 安装DRF框架 drf请求生命周期流程 请求模块：request对象 渲染模块： 安装DRF框架 pip install djangorestframework drf请求生命周期流程 根据应用中...urls.py,走as_view方法，但是视图类没有该方法，所以请求走的是APIView的as_view方法 在APIView的as_view调用父类(django原生View)的as_view，同时还禁用了...csrf 认证 在父类（django原生View）的as_view中dispatch方法请求走的又是APIView的dispatch #因为APIView也可以走dispatch,视图类是先继承...APIView,APIView中没有再去原生View中 完成任务方法交给视图类的请求函数处理，得到请求的响应结果， 返回给前台所以以后直接就从APIView的dispatch入口看源码 请求模块：request..._request等于原生request 2) 原生request对象的属性和方法都可以被drf的request对象直接访问(兼容) 3) drf请求的所有url拼接参数均被解析到query_params
，一般都是用def定义的函数视图，不过DRF更推荐使用class定义的类视图，这能让我们的代码更符合DRY（Don’t Repeat Yourself）设计原则： 使用APIView rest_framework.views.APIView...是DRF封装的API视图，继承了django.views.generic.base.View： 我们用它把函数视图改写成类视图，编辑snippets/views.py： from snippets.models...return Response(serializer.data) return Response(serializer.errors, status=status.HTTP_400...else: raise TypeError(‘view must be a callable or a list/tuple in the case of include().’) as_view()方法返回了一个内部定义的可调用函数...： 这是DRF提供的通用API类视图，mixins只提供了处理方法，views.py中的类要成为视图，还需要继承GenericAPIView，GenericAPIView继承了本文第一小节提到的rest_framework.views.APIView
刚开始写views.py模块的代码，一般都是用def定义的函数视图，不过DRF更推荐使用class定义的类视图，这能让我们的代码更符合DRY（Don't Repeat Yourself）设计原则： ?...使用APIView rest_framework.views.APIView是DRF封装的API视图，继承了django.views.generic.base.View： ?...return Response(serializer.data) return Response(serializer.errors, status=status.HTTP_400...raise TypeError('view must be a callable or a list/tuple in the case of include().') as_view()方法返回了一个内部定义的可调用函数...这是DRF提供的通用API类视图，mixins只提供了处理方法，views.py中的类要成为视图，还需要继承GenericAPIView，GenericAPIView继承了本文第一小节提到的rest_framework.views.APIView
dispatch函数完成请求分发 3）dispatch函数将请求方式映射成视图类的同名方法，完成请求的处理，得到相应 4）再将相应的结果一层层返回 """ 二.drf CBV 源码分析：APIView...""" 1）as_view()是入口，得到view函数地址，在范围view函数地址时局部禁用csrf认证 2）请求来了调用view函数，内部调用(APIView类的)dispatch函数完成请求分发 3...）dispatch函数 二次封装request、完成三大认证后，再将请求方式映射成视图类的同名方法，完成请求的处理，得到相应，再对相应做渲染处理 4）再将相应的结果一层层返回 """ 三.APIView...做的处理 as_view: 就干了一件事，禁用csrf认证 dispatch: 1）二次封装request 2）三大认证 四.drf 的局部渲染和全局渲染 通过看了源码我们对于渲染内容是JSONRenderer...from rest_framework.renderers import BrowsableAPIRenderer 局部设置 在我们定义基础APIView的类添加renderer_classes
使用场景： 重写 get_serializer_class和get_queryset,根据不同的操作返回不同的序列化器类和不同的查询集。...== 'latest'： # 返回latest操作对应的序列化器类 else: # 返回其他操作对应的序列化器类 def get_queryset(self)...返回latest操作所使用的查询集 else: # 返回其他操作所使用的查询集 2.路由Router(urls文件中使用) 作用：（重点） 配合视图集进行使用，动态生成视图集中处理函数的...DefaultRouter创建的对象，在访问url地址的时候，我们都可以在后面加一个 .json,那么后台会给我们返回json格式的数据。...limit=100&offset=400 可以在子类中定义的属性： default_limit 默认限制，默认值与 PAGE_SIZE设置一直 limitqueryparam limit参数名，默认'limit
在views_base中，我被 JsonResponse,HttpResponse这两个模块之间的有什么不同所引起好奇心，都是返回字符串，一个可以返回json，而另一个需要添加一些设置才能返回json。...基于一条真理： 1 网络传输的数据都是字符串！ 我将HTTPResponse中除了要返回的字符串，其他参数都删了，代替JsonResponse来作为return值。...二、apiview方式实现商品列表页 1.drf（Django REST framework）所需插件： 1 coreapi（1.32.0+） - 模式生成支持。...： 首先，我们的UserProfile表继承的django/admin自动创建的用户表AbstractUser， 然后，我们在UserProfile表中用__str__返回的是name字段（昵称），而drf...的request和response request.data返回请求主体的解析内容，这与django本身的request.POST+request.FILES属性类似。
功能： 1.视图中的request对象不再是Django中 HttpRequest类的对象，而是由DRF框架封装成的 Request类的对象。...2.响应时可以统一返回Response类的对象 3.异常处理:如果视图中抛出了未处理异常，DRF框架会自动对异常进行处理，并且会把处理之后的错误信息返回给客户端。...1.2.2GenericAPIView 继承于APIView，是APIView的子类，在APIView的基础上添加操作序列化器和数据库查询的方法。封装的这些方法，我们可以直接使用。...如果序列化器对前端发送的数据验证失败，返回400错误。...成功返回200，序列化器校验数据失败时，返回400错误。
DRF视图和常用功能 DRF视图 DRF视图类介绍 在DRF框架中提供了众多的通用视图基类与扩展类，以简化视图的编写。...APIView：DRF提供的所有视图的基类，继承View并扩展，具备了身份认证、权限检查、流量控制等功能。...APIView类 APIView：DRF提供的所有视图的基类，继承View并扩展，具备了身份认证、权限检查、流量控制等功能 创建项目 创建app并加入settings.py E:\workspace\...常用属性： request.data：返回POST提交的数据，与request.POST类似 request.query_params：返回GET URL参数，与request.GET类似 浏览器get..." http://127.0.0.1:8000/myapp/api/user5/ token自定义返回信息 需要重写返回信息函数 在app项目下的utils目录中新增重写信息： myapp/utils
一、使用 Django rest framework 认证组件 ①实例 假如用户想获取自己的订单信息，发送请求之后返回订单信息以 json 格式的数据返回。 ? 续 ? 续 ?...这了继承了 rest framework 中的 APIView，在 APIView 中将原生的 request 进行了封装，封装一些用于认证、权限的类，在请求来的时候，会依次通过 FirstAuthenticate...第二步，由于子类 APIView 已经实现了 dispatch 方法，接着返回 APIView 中的 dispatch 方法。 ? 第三步，然后会发现 drf 对原生 request 做的操作。 ?...到这就可以看到 request 在 drf 中大概的流程。...③ drf 认证流程 在上面的第四步和第五步可以看到 APIView 中的两个方法 initialize_request，initial ?
前言 如果我们不用使用drf那套认证规则，我们想自定义认证类，那么我们首先要知道，drf本身是如何定义认证规则的，也就是要查看它的源码是如何写的 源码分析 源码的入口在APIView.py文件下的dispatch...request的user方法，request代表的是drf的Request，所以我们进入drf的Request类中查找user方法属性，源码如下: def user(self):..._user 上述代码的意思是：返回与当前请求关联的用户，由提供给请求的身份验证类进行身份验证。..._not_authenticated() 我们可以看到self.authenticators验证器其实是调用父类APIView的authenticators，APIView的authenticators..."message": "drf get ok" } 以上的测试，就代表我们自定义的认证类起作用了 发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/164879.html
类型的数据包才能被解析 parser_classes = [JSONParser] pass 异常模块 (走到逻辑异常都能被控制) 为什么要自定义异常模块 1）所有经过drf的APIView...视图类产生的异常，都可以提供异常处理方案 2）drf默认提供了异常处理方案(rest_framework.views.exception_handler)，但是处理范围有限 3）drf提供的处理方案两种...，处理了返回异常现象，没处理返回None(后续就是服务器抛异常给前台) 4）自定义异常的目的就是解决drf没有处理的异常，让前台得到合理的异常信息返回，后台记录异常具体信息 如何使用：自定义exception_handler...去处理 （******） 2）判断处理的结果(返回值)response，有值代表drf已经处理了，None代表drf处理不了的异常， 需要自定义去处理 （******） # 自定义异常处理文件exception...= drf_exception_handler(exc, context) # 为空，就是drf框架处理不了的异常 if response is None: #处理之后为空，再进行自定义的二次处理
DRF的Request对象和Response对象 一旦使用了DRF的视图，那么传入视图的Request对象不在是Django的Request对象，而是DRF封装过后的Request对象。...同样，DRF建议使用封装过的Response来返回HTTP响应，使用该类构造响应对象时，响应的具体数据内容会被转换（render渲染）成符合前端需求的类型。...无论请求方式是什么，URL中的参数，我们在DRF中总是使用request.query_params来获取。...使用Response类只是为返回内容协商的 Web API 响应提供了一个更好的接口，可以呈现为多种格式。...不过DRF官方还是建议我们对继承自APIView类或使用@api_view进行装饰的函数，都返回Response对象。 使用了Response对象返回，默认会带有一定的样式。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
