我们知道django rest_framework里面的设计规范基本都遵循restful规范,method操作规范同样如此。
- 通过method区分是什么操作
-get 表示获取资源
-post 表示新增
-put/patch表示更新
-delete表示删除
按照这样规范的确比较好,但是如果完全按照restful规范设计API,在django的url文件中,会多出好多url地址。这样设计,比FBV设计出来url少不了多少。比如进行用户操作。按照restful规范,增删改查用户,和修改用户密码会设计到二个url中。把这五个操作放在一个视图view里面完全可以,同属于一个操作用户。
我们公司是这样操作的,这五个放在一个view视图中,同时url也用一个url,method操作全部使用post,在每个post请求里面加一个_method用于指明操作。
编写一个类,里面放一个post方法,读取请求_method的值,反射到对应的方法上面去。再让功能视图类继承刚才编写的那个类。
下面用我们公司系统里面一个直播模块解释下上面的方法:
# 课程直播管理
class CourseLiveBroadcast(ClassMethod, APIView):
@system_log("60", "B", "登录", "登录课程直播管理页面")
def get(self, request, *args, **kwargs):
pass
@system_log("60", "B", "查询", "查询课程直播管理数据")
def select(self, request):
pass
@system_log("60", "B", "新增", "新增课程直播管理数据")
def add(self, request):
pass
@system_log("60", "B", "修改", "修改课程直播管理数据")
def update(self, request):
pass
@system_log("60", "B", "启用", "启用课程直播管理数据")
def stop(self, request):
pass
@system_log("60", "B", "生成", "从新生成直播地址")
def intended_effective(self, request):
pass
@system_log("60", "B", "查询", "查询在线人数")
def online(self, request):
pass
@system_log("60", "B", "生成", "生成二维码图片")
def save_image(self, request):
pass
@system_log("60", "B", "查询", "查询直播回放")
def select_playback(self, request):
pass
@system_log("60", "B", "停用", "停用直播回放")
def stop_playback(self, request):
pass
上面的CourseLiveBroadcast继承了rest_framework的APIView的同时继承了ClassMethod,ClassMethod里面只有一个方法,post方法,post方法读取请求_method的值,反射到对应的方法上面去
# Framework规范请求
class ClassMethod(object):
"""
Framework规范请求
"""
# POST逻辑
def post(self, request, *args, **kwargs):
"""
POST逻辑
"""
# 进行认证
if request.user:
# 获取请求类型
_method = request.POST.get("_method")
# 判断方法是否存在
if not hasattr(self, _method):
return JsonResponse({"code": "0001", "msg": "逻辑类型不存在", "data": {"data": None}}, safe=False)
# 反射到对应方法
return getattr(self, _method)(request)
else:
return JsonResponse({"code": "0001", "msg": "token认证失败", "data": {"data": None}}, safe=False)