django的drf入门规范

最新推荐文章于 2026-04-13 10:55:24 发布

原创最新推荐文章于 2026-04-13 10:55:24 发布 · 354 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#django #python #后端

python 专栏收录该内容

56 篇文章

订阅专栏

本文介绍了Django Rest Framework（DRF）的入门规范，包括web应用模式、API接口设计、Postman接口测试工具的使用以及RESTful接口的详细规范。此外，文章还探讨了序列化在API开发中的重要性和DRF框架的特点。

drf入门规范

一、web应用模式

在开发wdb应用时，有两种应用方式

1、前后端不分离

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DIuZRcLc-1635934913862)(image-20210831100921267.png)]

2、前后端不分离

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rdtYnJsZ-1635934913863)(image-20210831100951626.png)]

二、API接口

为了在团队内部形成共识、防止个人习惯差异引起的混乱，我们需要找到一种大家都觉得很好的接口实现规范，而且这种规范能够让后端写的接口，用途一目了然，减少双方之间的合作成本。

通过网络，规定了前后端信息交互规则的url链接，也就是前后端信息交互的媒介

Web API接口和一般的url链接还是有区别的，Web API接口简单概括有下面四大特点

url：长得像返回数据的url链接

[]: https://api.map.baidu.com/place/v2/search

请求方式：get、post、put、patch、delete
请求参数：json或xml格式的key-value类型数据

"""
ak：6E823f587c95f0148c19993539b99295
region：上海
query：肯德基
output：json
"""

响应结果：json或xml格式的数据
- 上方请求参数的output参数值决定了响应数据的格式
- 数据

# xml格式
https://api.map.baidu.com/place/v2/search?ak=6E823f587c95f0148c19993539b99295&region=%E4%B8%8A%E6%B5%B7&query=%E8%82%AF%E5%BE%B7%E5%9F%BA&output=xml
#json格式
https://api.map.baidu.com/place/v2/search?ak=6E823f587c95f0148c19993539b99295&region=%E4%B8%8A%E6%B5%B7&query=%E8%82%AF%E5%BE%B7%E5%9F%BA&output=json
{
    "status":0,
  	"message":"ok",
    "results":[
        {
            "name":"肯德基(罗餐厅)",
            "location":{
                "lat":31.415354,
                "lng":121.357339
            },
            "address":"月罗路2380号",
            "province":"上海市",
            "city":"上海市",
            "area":"宝山区",
            "street_id":"339ed41ae1d6dc320a5cb37c",
            "telephone":"(021)56761006",
            "detail":1,
            "uid":"339ed41ae1d6dc320a5cb37c"
        }
      	...
		]
}

三、Postman：接口测试工具

Postman是一款接口调试工具，是一款免费的可视化软件，同时支持各种操作系统平台，是测试接口的首选工具。

Postman可以直接从官网：https://www.getpostman.com/downloads/下载获得，然后进行傻瓜式安装。

四、restful接口规范

REST全称是Representational State Transfer，中文意思是表述（编者注：通常译为表征性状态转移）。它首次出现在2000年Roy Fielding的博士论文中。

RESTful是一种定义Web API接口的设计风格，尤其适用于前后端分离的应用模式中。

这种风格的理念认为后端开发任务就是提供数据的，对外提供的是数据资源的访问接口，所以在定义接口时，客户端访问的URL路径就表示这种要操作的数据资源。

事实上，我们可以使用任何一个框架都可以实现符合restful规范的API接口。

1、数据的安全保障

url链接一般都采用https协议进行传输

注：采用https协议，可以提高数据交互过程中的安全性

2、url特征表现

用api关键字标识接口url：
- https://api.baidu.com
- https://www.baidu.com/api
注：看到api字眼，就代表该请求url链接是完成前后台数据交互的

3、多数据版本共存

在url链接中标识数据版本
- https://api.baidu.com/v1
- https://api.baidu.com/v2
注：url链接中的v1、v2就是不同数据版本的体现（只有在一种数据资源有多版本情况下）

4、数据既资源，均使用名词（可用复数）

接口一般都是完成前后台数据的交互，交互的数据我们称之为资源
- https://api.baidu.com/users
- https://api.baidu.com/books
- https://api.baidu.com/book
注：一般提倡用资源的复数形式，在url链接中奖励不要出现操作资源的动词，错误示范：https://api.baidu.com/delete-user
特殊的接口可以出现动词，因为这些接口一般没有一个明确的资源，或是动词就是接口的核心含义
- https://api.baidu.com/place/search
- https://api.baidu.com/login

5、资源操作由请求方式决定

操作资源一般都会涉及到增删改查，我们提供请求方式来标识增删改查动作
- https://api.baidu.com/books - get请求：获取所有书
- https://api.baidu.com/books/1 - get请求：获取主键为1的书
- https://api.baidu.com/books - post请求：新增一本书书
- https://api.baidu.com/books/1 - put请求：整体修改主键为1的书
- https://api.baidu.com/books/1 - patch请求：局部修改主键为1的书
- https://api.baidu.com/books/1 - delete请求：删除主键为1的书

6、过滤在通过在url上传参传递搜索条件

https://api.example.com/v1/zoos?limit=10：指定返回记录的数量
https://api.example.com/v1/zoos?offset=10：指定返回记录的开始位置
https://api.example.com/v1/zoos?page=2&per_page=100：指定第几页，以及每页的记录数
https://api.example.com/v1/zoos?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序
https://api.example.com/v1/zoos?animal_type_id=1：指定筛选条件

7、响应状态码

7.1 正常响应

响应状态码2xx
- 200：常规请求
- 201：创建成功

7.2 重定向响应

响应状态码3xx
- 301：永久重定向
- 302：暂时重定向

7.3 客户端异常

响应状态码4xx
- 403：请求无权限
- 404：请求路径不存在
- 405：请求方法不存在

7.4 服务器异常

响应状态码5xx
- 500：服务器异常

8、错误处理

{
    error: "无权限操作"
}

9、返回结果，针对不同操作，服务器向用户返回的结果应该符合以下规范

GET /collection：返回资源对象的列表（数组）
GET /collection/resource：返回单个资源对象
POST /collection：返回新生成的资源对象
PUT /collection/resource：返回完整的资源对象
PATCH /collection/resource：返回完整的资源对象
DELETE /collection/resource：返回一个空文档

10、需要url请求的资源需要访问资源的请求链接

# Hypermedia API，RESTful API最好做到Hypermedia，即返回结果中提供链接，连向其他API方法，使得用户不查文档，也知道下一步应该做什么
{
  	"status": 0,
  	"msg": "ok",
  	"results":[
        {
            "name":"肯德基(罗餐厅)",
            "img": "https://image.baidu.com/kfc/001.png"
        }
      	...
		]
}

比较好的接口返回

# 响应数据要有状态码、状态信息以及数据本身
{
  	"status": 0,
  	"msg": "ok",
  	"results":[
        {
            "name":"肯德基(罗餐厅)",
            "location":{
                "lat":31.415354,
                "lng":121.357339
            },
            "address":"月罗路2380号",
            "province":"上海市",
            "city":"上海市",
            "area":"宝山区",
            "street_id":"339ed41ae1d6dc320a5cb37c",
            "telephone":"(021)56761006",
            "detail":1,
            "uid":"339ed41ae1d6dc320a5cb37c"
        }
      	...
		]
}

五、序列化

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

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

例如：我们在django中获取到的数据默认是模型对象，但是模型对象数据无法直接提供给前端或别的平台使用，所以我们需要把数据进行序列化，变成字符串或者json数据，提供给别人。

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

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

六、drf规范（django rest framework）

核心思想: 缩减编写api接口的代码

Django REST framework是一个建立在Django基础之上的Web 应用开发框架，可以快速的开发REST API接口应用。在REST framework中，提供了序列化器Serialzier的定义，可以帮助我们简化序列化与反序列化的过程，不仅如此，还提供丰富的类视图、扩展类、视图集来简化视图的编写工作。REST framework还提供了认证、权限、限流、过滤、分页、接口文档等功能支持。REST framework提供了一个API 的Web可视化界面来方便查看测试接口。

1、django rest framework的特点

提供了定义序列化器Serializer的方法，可以快速根据 Django ORM 或者其它库自动序列化/反序列化；
提供了丰富的类视图、Mixin扩展类，简化视图的编写；
丰富的定制层级：函数视图、类视图、视图集合到自动生成 API，满足各种需要；
多种身份认证和权限认证方式的支持；[jwt]
内置了限流系统；
直观的 API web 界面；
可扩展性，插件丰富

在Django里使用restframework需要在INSTALLED_APPS里添加"rest_framework"

接下来就可以使用DRF提供的功能进行api接口开发了。在项目中如果使用rest_framework框架实现API接口，主要有以下三个步骤：

将请求的数据（如JSON格式）转换为模型类对象
操作数据库
将模型类对象转换为响应的数据（如JSON格式）

2、CBV源码分析

# urls.py
path('bookview/',views.bookview.as_view()),
# views.py
from rest_framework.views import View
class bookview(View):
    def get(self):
        return HttpResponse('ok')

源码分析

"""
进入View源码中，首先找到as_view方法
"""
@classonlymethod # 类方法，直接由类调用
def as_view(cls, **initkwargs):
    def view(request, *args, **kwargs):
    ………………
    	return self.dispatch(request, *args, **kwargs) # 此处调用了dispatch方法
	return view # 将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_allowed
        return handler(request, *args, **kwargs)
"""
dispatch方法主要是对views.py里的bookview里的方法进行判断
判断其方法是否在http_method_names里；
http_method_names = ['get', 'post', 'put', 'patch', 'delete', 'head', 'options', 'trace']
如果存在使用getattr进行反射，此时的self便是bookview类
"""

3、APIView源码分析

# urls.py
path('bookview/',views.bookview.as_view()),
# views.py
from rest_framework.views import APIView
class bookview(View):
    def get(self):
        return HttpResponse('ok')

源码分析

"""
进入到APIView源码里
"""
class APIView(View):
    ……
    @classmethod
    def as_view(cls, **initkwargs):
        ……
        view = super().as_view(**initkwargs)
        view.cls = cls
        view.initkwargs = initkwargs

        # Note: session based authentication is explicitly CSRF validated,
        # all other authentication is CSRF exempt.
        return csrf_exempt(view)
"""
能够看到APIView实际上就是继承View，并且直接继承了View里的as_view方法丝毫未改
唯独有一点不同就是return csrf_exempt(view)
在django的中间间中有这样一行代码'django.middleware.csrf.CsrfViewMiddleware',
这便是防止csrf跨站请求伪造的
而csrf_exempt(view)就是@csrf_exempt装饰器的另一种写法，两者一摸一样
"""

APIView执行流程分析

# 请求来了，会执行views.BookView.as_view()(request)---->触发APIView的as_view
    @classmethod
    def as_view(cls, **initkwargs):
        view = super().as_view(**initkwargs) # 调用了View的as_view
        return csrf_exempt(view) # 去掉了csrf的认证，跟原来加装饰器一样
# 假设get请求来了，执行view()--最重要的-->self.dispatch()--》APIView的
    def dispatch(self, request, *args, **kwargs):
        # 把原来的request对象，包装成了新的request对象，是drf的request
        request = self.initialize_request(request, *args, **kwargs)
        try:
            # 执行了三大认证：认证，权限，频率
            self.initial(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
            # 真正的执行视图类中的方法，如果有异常，被捕获了
            response = handler(request, *args, **kwargs)
        except Exception as exc:
            response = self.handle_exception(exc)
        return self.response
    
    
# 重点：
	apiview：干了三件事
    	-把老的request对象包装成了新的request对象
        	-通过APIView的initialize_request，包装的
            -以后再在视图类中用的request对象，都是新的
        -在执行视图类中的方法之前，执行了三大认证
        	self.perform_authentication(request)
            self.check_permissions(request)
            self.check_throttles(request)
        -处理全局异常
        
        
    只要继承了APIView，以后用的request对象，就是drf的request对象了
    在执行视图类的方法之前，会先执行三大认证，如果有异常，会被捕获并处理

4、request源码解析

# view.py
from rest_framework.request import Request
from rest_framework.views import APIView

class bookview(APIView):
    def get(self,request):
        return HttpResponse('ok')
"""
# from rest_framework.request import Request
# 重点
	-老的django的request在drf的request._request中
    -新的request用起来跟原来一模一样用，没有一点区别
    	-对象.属性，会触发类的 __getattr__方法
        -重写了__getattr__
        return getattr(self._request, attr)
    -新的request多个一个data属性--》所有post提交的数据，都放在它中
"""