django restframework(简称drf)本质上其实就是一个别人编写好的app,里面集成了很多编写restful API的功能功能。
其目录中有很多我们以前写django程序见到过的,因为它就是一个别人写好了的app,我们拿来用。
因此 每次新建项目时要记得在settings中注册app。
同时在settings中也要加上如下字典,以后drf相关的全局配置都会在该字典中添加。
REST_FRAMEWORK = {
}
一、基本流程分析*
drf为我们封装了许许多多的功能,我们要了解其大概才能在日后的使用中更加灵活。
当路由匹配到如上user的时候,执行其后面的views.UserView中的as_view方法。我们可以看到在我们自己写的类UserView中并没有as_view方法,但它继承于**APIView,**我们可以在1中看到,APIView的as_view继承了父类View(也就是CBV模式下最先学习的基类)的全部功能,此时我们获得了原本的view函数。在1的retrun中我们看到了csrf_exempt(view),这一步的过程其实就像我们以前去掉csrf_token认证引入的装饰器一样,用于去除csrf_token认证。我们以后选择用jwt进行认证。
期间2中还执行了dispatch方法,由于我们自己写的UserView中没有重写dispatch,它向上找到APIView的dispatch。我们与View基类的dispatch做对比,看到它除了与基类同样运用反射获取请求方式外,其前后还分别对request和response进行了封装。详细内容后面会详细讲。
drf中重写了 as_view
和dispatch
方法,其实就是在原来django的功能基础上添加了一些功能,例如:
-
as_view
,免除了csrf 验证,一般前后端分离不会使用csrf token认证(后期会使用jwt认证)。 -
dispatch
,内部添加了 版本处理、认证、权限、访问频率限制等诸多功能(后期逐一讲解)。
二、请求数据的封装
以前我们通过django开发项目时,视图中的request是 django.core.handlers.wsgi.WSGIRequest
类的对象,其中包含了请求相关的所有数据。
# Django FBV
def index(request):
request.method
request.POST
request.GET
request.body
# Django CBV
from django.views import View
class UserView(View):
def get(self,request):
request.method
request.POST
request.GET
request.body
而在使用drf框架时,视图中的request是rest_framework.request.Request
类的对象,其是又对django的request进行了一次封装,包含了除django原request对象以外,还包含其他后期会使用的其他对象。
from rest_framework.views import APIView
from rest_framework.response import Response
class UserView(APIView):
def get(self, request, *args, **kwargs):
return Response({"code": 1000, "data": "xxx"})
def post(self, request, *args, **kwargs):
return Response({"code": 1000, "data": "xxx"})
注:此时你看到的request,不再是曾经django中的request,而是又被封装了一层,内部包含:django的request、认证、解析器等。
在源码中,大概是这样:有一个rest_framework.request.Request类,我们最后获得的request=Request(request, 认证,分页…)
Request源码:
# rest_framework.request.Request 类
class Request:
"""
Wrapper allowing to enhance a standard `HttpRequest` instance.
Kwargs:
- request(HttpRequest). The original request instance. (django中的request)
- parsers(list/tuple). The parsers to use for parsing the
request content.
- authenticators(list/tuple). The authenticators used to try
authenticating the request's user.
"""
def __init__(self, request, parsers=None, authenticators=None,negotiator=None, parser_context=None):
self._request = request
self.parsers = parsers or ()
self.authenticators = authenticators or ()
...
@property
def query_params(self):
"""
More semantically correct name for request.GET.
"""
return self._request.GET
@property
def data(self):
if not _hasattr(self, '_full_data'):
self._load_data_and_files()
return self._full_data
def __getattr__(self, attr):
try:
return getattr(self._request, attr) # self._request.method
except AttributeError:
return self.__getattribute__(attr)
我们从源码中可以看到,想要从请求中获取数据,有两种方法:
第一种:
request._request.method
request._request.GET
request._request.POST
request._request.body
第二种:
# 直接读取新request对象中的值,一般此处会对原始的数据进行一些处理,方便开发者在视图中使用。
request.query_params # 内部本质上就是 request._request.GET
# 内部读取请求体中的数据,并进行处理,例如:请求者发来JSON格式,他的内部会对json字符串进行反序列化。
request.data
# 通过 __getattr__ 去访问 request._request 中的值
request.method
request.method这样的可以通过反射获取,因此不需要改变。这里我们用request.query_params 替换了request.GET,request.data替换了request.POST.
值得一提的是,request.data会对收到的json格式自动进行反序列化。此外无论是content-type: url-form-encoded还是content-type: application/json,该方法都可以获取到内容。
三、版本管理
在restful规范中要去,后端的API中需要体现版本。
drf框架中支持5种版本的设置,这里我们只介绍常用的两种。
1. URL的GET参数传递版本
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.versioning import QueryParameterVersioning
class UserView(APIView):
versioning_class = QueryParameterVersioning
def get(self, request, *args, **kwargs):
print(request.version)
return Response({"code": 999, "data": "成功了"})
此时我们访问:127.0.0.1/api/user/ 输出结果为None
访问:127.0.0.1/api/userversion=v1 输出结果为v1
访问:127.0.0.1/api/userxx=oo 输出结果为None
即默认情况下通过get请求携带参数只认version这一字符串,等号后面是什么结果输出就是什么。
简化:
settings中配置
REST_FRAMEWORK = {
"VERSION_PARAM": "v", # 改名字
"DEFAULT_VERSION": "v1", # 默认版本 不传的话就是v1
"ALLOWED_VERSIONS": ["v1", "v2", "v3"], # 不在里面返回404 Invalid version in query parameter.
# 全局配置不用在视图类中写versioning_class = QueryParameterVersioning了(有优先级)
"DEFAULT_VERSIONING_CLASS": "rest_framework.versioning.QueryParameterVersioning"
}
此时可以不在视图中声明versioning_class = QueryParameterVersioning了。但由于又是全局配置,版本还好,后面一些权限类的不想要可以在视图类中重新声明versioning_class为空就好了。
按照上面的配置,我们访问127.0.0.1/api/userv=xx, xx不在允许的版本中,直接返回404不执行函数。访问127.0.0.1/api/userv=v2,print(request.version)输出v2。
2. URL路径传递
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.versioning import URLPathVersioning
class UserView(APIView):
versioning_class = URLPathVersioning
def get(self, request, *args, **kwargs):
print(request.version)
return Response({"code": 999, "data": "成功了"})
此时路由中要留个位置写版本:
path('api/<str:v>/user/', views.UserView.as_view()),
注:我们上面改过settings里的名字了,从默认的version改为了v,因此这里命名也必须是v。由于该种方法写在了视图类内部,比settings配置的QueryParameterVersioning优先级更高,因此我们可以访问127.0.0.1/api/v1/user/、127.0.0.1/api/v2/user/、127.0.0.1/api/v2/user/,由于该路由参数必须填写,因此不采取什么错的情况下,settings中的默认版本与该方法无关。
REST_FRAMEWORK = {
"VERSION_PARAM": "v", # 改名字
"ALLOWED_VERSIONS": ["v1", "v2", "v3"], # 不在里面返回404 Invalid version in query parameter.
"DEFAULT_VERSIONING_CLASS": "rest_framework.versioning.URLPathVersioning"
}
一种解决不得不填写的办法:
urlpatterns = [
# 两个路由映射同一个类
path('api/user/', views.UserView.as_view()),
path('api/<str:v>/user/', views.UserView.as_view()),
]
四、认证
在开发后端的API时,不同的功能会有不同的限制,例如:
-
无需认证,就可以访问并获取数据。
-
需认证,用户需先登录,后续发送请求需携带登录时发放的凭证(后期会讲jwt)
建表如下:
class UserInfo(models.Model):
username = models.CharField(verbose_name="用户名", max_length=32)
password = models.CharField(verbose_name="密码", max_length=64)
token = models.CharField(verbose_name="TOKEN", max_length=64, null=True, blank=True)
我们设定:从url中获取token,如果没有token或者token不正确或token对应的用户不存在,令其抛出异常。否则通过认证。
代码如下:
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework.authentication import BaseAuthentication
from rest_framework.exceptions import AuthenticationFailed
from app01.models import UserInfo
class MyAuthentication(BaseAuthentication):
def authenticate(self, request):
token = request.query_params.get('token')
if not token:
raise AuthenticationFailed({"code": 1001, "error": "认证失败"})
user_obj = UserInfo.objects.filter(token=token).first()
if not user_obj:
raise AuthenticationFailed({"code": 1001, "error": "认证失败"})
return user_obj, token
def authenticate_header(self, request):
return 'Bearer realm="API"'
class OrderView(APIView):
authentication_classes = [MyAuthentication, ]
def get(self, request, *args, **kwargs):
return Response({"code": 999, "data": "成功了"})
此时我们不带token访问(后面后会通过postman进行调试)
当我们带上正确token:
在视图类中设置类变量 authentication_classes
的值为 认证类 MyAuthentication
,表示此视图在执行内部功能之前需要先经过 认证。
认证类的内部就是去执行:authenticate
方法,根据返回值来表示认证结果。
-
抛出异常AuthenticationFailed,表示认证失败。内部还会执行
authenticate_header
将返回值设置给响应头WWW-Authenticate
-
返回含有两个元素的元组,表示认证成功,并且会将元素的第1个元素赋值给
request.user
、第2个值赋值给request.auth
。第1个值,一般是用户对象。
第2个值,一般是token -
返回None,表示继续调用后续的认证类 进行认证(上述案例未涉及)
我们也看到了authentication_classes列表里面可以添加多个认证类,比如
authentication_classes = [MyAuthenticationA, MyAuthenticationB, ]
三种情况
- 认证类A正常结束,返回一个用户对象和token:return user_obj, token结果:在
request.user
和request.auth
赋值,后续代码可以使用,此时认证结束不再执行认证类B。 - 认证类A抛出异常,此时认证结束不再执行认证类B。
- 认证类A返回一个None:**return None,**表示继续调用后续的认证类。
如果所有的认证类`authenticate`都返回了None,则默认 request.user= AnonymousUser() (匿名用户对象) 和 request.auth=None,也可以通过修改配置文件来修改默认值。
REST_FRAMEWORK = {
"UNAUTHENTICATED_USER": lambda: None,
"UNAUTHENTICATED_TOKEN": lambda: None,
}
”返回None“的应用场景:
当某个API,已认证 和 未认证 的用户都可以方法时,比如:
已认证用户,访问API返回该用户的视频播放记录列表。
未认证用户,访问API返回最新的的视频列表。
注意:不同于之前的案例,之前案例是:必须认证成功后才能访问,而此案例则是已认证和未认证均可访问。
class OrderView(APIView):
authentication_classes = [TokenAuthentication, ]
def get(self, request, *args, **kwargs):
if not request.user: # 这样写前提是settings里修改了名字 匿名改为None
return Response({"code": "999", "data": "未认证看到的"})
return Response({"code": "999", "data": "认证了看到的"})
关于多个认证类
一般情况下,编写一个认证类足矣。
当项目中可能存在多种认证方式时,就可以写多个认证类。例如,项目认证支持:
-
在请求中传递token进行验证。
-
请求携带cookie进行验证。
-
请求携带jwt进行验证(后期讲)。
-
请求携带的加密的数据,需用特定算法解密(一般为app开发的接口都是有加密算法)
-
…
全局配置:
REST_FRAMEWORK = {
"UNAUTHENTICATED_USER": lambda: None,
"UNAUTHENTICATED_TOKEN": lambda: None,
"DEFAULT_AUTHENTICATION_CLASSES":["xxxx.xxxx.类名","xxxx.xxxx.类名",]
}
对于一些不需要认证的url:,视图类中声明:authentication_classes = []
五、权限
认证:根据用户携带的 token/其他 获取当前用户信息。
权限:读取认证中获取的用户信息,判断当前用户是否有权限访问,例如:普通用户、管理员、超级用户,不同用户具有不同的权限。
创建表结构如下:
class UserInfo(models.Model):
role_choices = ((1, "普通用户"), (2, "管理员"), (3, "超级管理员"),)
role = models.IntegerField(verbose_name="角色", choices=role_choices, default=1)
username = models.CharField(verbose_name="用户名", max_length=32)
password = models.CharField(verbose_name="密码", max_length=64)
token = models.CharField(verbose_name="TOKEN", max_length=64, null=True, blank=True)
则:
class MyAuthentication(BaseAuthentication):
def authenticate(self, request):
token = request.query_params.get('token')
if not token:
raise AuthenticationFailed({"code": 1001, "error": "认证失败"})
user_obj = UserInfo.objects.filter(token=token).first()
if not user_obj:
raise AuthenticationFailed({"code": 1001, "error": "认证失败"})
return user_obj, token
def authenticate_header(self, request):
return 'Bearer realm="API"'
class PermissionA(BasePermission):
message = {"code": 1003, "data": "无权访问"} # 无权访问的话返回的就是它了
def has_permission(self, request, view):
exists = request.user.role
if exists == 2:
return True
return False
def has_object_permission(self, request, view, obj):
pass
class OrderView(APIView):
authentication_classes = [MyAuthentication, ]
permission_classes = [PermissionA, ]
def get(self, request, *args, **kwargs):
return Response({"code": 999, "data": "成功了"})
这里我们简写,执行权限前必先执行了认证。我们这里让认证最后通过时必须是一个完整的用户对象,这样我们在Permission中写的代码request.user.role就不会报错(匿名用户或者None是.不出来role的)。
我们访问127.0.0.1:8000/api/ordertoken=df6e0d2f-4686-4544-b85b-45bde26f0c8d
修改身份再次访问:
关于多个权限类
当开发过程中需要用户同时具备多个权限(缺一不可 错一不可)时,可以用多个权限类来实现。
权限组件内部处理机制:按照列表的顺序逐一执行 has_permission
方法,如果返回True,则继续执行后续的权限类;如果返回None或False,则抛出权限异常并停止后续权限类的执行。
关于 has_object_permission【欠】
当我们使用drf来编写 视图类时,如果是继承 APIView
,则 has_object_permission
不会被执行(没用)但是,当我们后期学习了 视图类的各种骚操作之后,发现视图也可以继承 GenericAPIView
,此时 有可能 会执行 has_object_