rest_framework接口开发流程及接口功能组成
使用restframework框架开发接口，方式应该有6、7种，每个人的习惯不同，用的方法也不一样，再次不再一一详述。
我比较常用：ModelSerializer+GenericAPIView
原因是用视图函数+装饰器、视图类+继承APIView、或者混入Mixin这三种封装层次有点低，用一个封装层次低的接口，通常意味着你需要写更多的代码，后期也需投入更多的精力去维护它，当然，好处是写出来的代码比较容易看懂；而使用ViewSets(视图集)则刚好相反，ViewSets封装了GenericAPIView，它显得有些画蛇添足，过高的封装层次可能会让你感到云里雾里，当然，好处是用熟了之后会很爽。
所以，在能理解和接受的程度与接口封装的层次两方面来权衡，我选择了GenericAPIView来写视图，ModelSerializer当然也比单纯的Serializer更好用，写更少的代码，做更多的事。
1 Django rest_framework开发的一个符合RESTful标准的接口组成及功能
Django框架它整个采用的是MVT的架构，这三部分各司其职，由M负责与数据库的实际交互；V负责业务逻辑；T负责接受请求与展示响应(实际就是前端)。那我们可以这么理解，只要有一个东西它具备了接受请求(入参)与展示响应(返回值)的功能，我们就可以把它当成T，因为它具备了T的功能。前后端不分离的时候，一切都是那么的美好。
当前后端分离的时候，我们突然发现，T不见了。那么谁来充当T的角色呢，没错是Serializer(负责接受请求与展示响应)。这样一来，前后端分离与不分离，就有了一个统一的架构，也即一个接口通常由三大主要的部分组成：模型、视图、序列化器。
1.1 模型M(models.py)
在Django框架的MVT架构中，M承担了与数据库进行交互的功能，但是由于我们用的是ORM，所以只需要将python对象映射到数据模型即可，也就是定义python对象，并在该对象中声明相应的字段。需要注意的一点是，在定义python对象之前，需要先绘制ER图，明确实体间的关系，确保每一个实体，都至少遵循第三范式(3NF)。
说明：前后端分离与不分离，models并没有什么区别
1.2 序列化器T(Serializers.py)
前后端不分离的时候，T其实就是前端，接受请求并返回响应数据。
前后端分离的时候，序列化器承担了这个功能，接受前端请求返回响应数据。
如果使用ModelSerializer来定义序列化器，那么它大概长这个样子：
"""
序列化器
"""
from rest_framework import serializers
from .models import *
import re
class MyModelSerializer(serializers.ModelSerializer):
"""
MyModel 序列化器
"""
class Meta:
"""
model 模型
fields 接口入参
extra_kwargs 入参的约束
"""
model = MyModel
fields = ('name', 'mobile')
extra_kwargs = {
'mobile': {
'write_only': True,
'min_length': 8,
'max_length': 16,
}
}
def validate_name(self, name):
"""
对name的校验
"""
if User.objects.filter(username=username).count():
raise serializers.ValidationError("该用户名已被注册")
return name
def validate_mobile(self, mobile):
"""
判断手机号格式
判断手机号是否已注册
"""
# 注册
if User.objects.filter(mobile=mobile).count():
raise serializers.ValidationError("该手机号已被注册")
# 判断手机号码格式是否有误
REGEX_MOBILE = '1[358]\d{9}$|^147\d{8}$|^176\d{8}$'
# 格式
if not re.match(REGEX_MOBILE, mobile):
raise serializers.ValidationError("手机号格式有误")
return mobile
def create(self, validated_data):
"""
validated_data 通过校验的数据 是一个字典
Serializer中重写create可以对数据做一些修改
最终将返回一个实例 该实例会给到对应的视图View
"""
user = super().create(validated_data)
# Your code
return user
在序列化器Serializer中，容易让人感到困惑的可能就是前端字段校验这一块。其实，我们回到Serializers的功能接受前端请求返回响应数据，就能明白为什么它要序列化与反序列化。
- 序列化：python对象转变为可传输(可被用于前端渲染)的JSON格式(也可能是xml等)字符串，究其原因是因为我们用的ORM，第一步ORM读数据，拿出来的是一个查询集(set对象)，需要把它变成前端喜欢的样子。
- 反序列化：字符串变为python对象。从前端得到的入参，必然是字符串格式，想要把它存到数据库里，还得靠ORM，但是ORM喜欢的是python对象，所以需要一个反序列化的过程。
在反序列化的过程中，我们不希望用户输入一些非法的参数，所以要在Serializer中定义入参的约束与自定义的校验方式，校验通过则返回一个模型的实例给视图，否则返回错误信息。
这就是Serializer的功能与Model及View之间的关系。
1.3 视图V(views.py)
模型和序列化器固然重要，但是视图才是核心，因为通常情况下，业务逻辑都集中在views中，由视图完成。
在视图中你可以通过重写get/create方法，完成业务逻辑。
如果你像我一样使用的是GenericAPIView来写视图函数，那么你的View应该长这个样子：
class MyModelCreateView(generics.CreateAPIView):
"""
创建视图
"""
# permission_classes = [permissions.IsAuthenticated]
queryset = MyModel.objects.all()
serializer_class = MyModelSerializer
def post(self, request, *args, **kwargs):
"""
重写post 四核可以不用重写
"""
serializer_data = MyModelSerializer(data=request.data)
if serializer_data.is_valid():
return super().post(request, *args, **kwargs)
else:
return Response(serializer_data.errors)
def create(self, request, *args, **kwargs):
"""
重写create 写自己的业务逻辑
如果继承的是ListAPIView 就重写create
"""
# 获取前端传入的数据
field= request.POST.get("xx")
# Your code
return JsonResponse(
data={
'data': data,
'msg': 'OK',
'code': 1,
},
safe=False
)
重写create/get方法时，通过reques获取从前端传过来的入参，拿到入参之后，你就可以写自己的业务逻辑了。
2 Django DRF 接口开发步骤
- 模型设计，需要注意关系规范化
- 序列化器，需要知道哪些是入参，分别需要怎样的约束
- 视图，写业务逻辑、权限配置、过滤查询分页等
我通常是先写模型，然后是序列化器，最后再写业务逻辑以及接口的其他功能，每个人的方法可能不同，也就不详述了。