浅析Django接口版本控制
一、前言
在RESTful
规范中,有关版本的问题,用restful
规范做开放接口的时候,用户请求API
,系统返回数据。但是难免在系统发展的过程中,不可避免的需要添加新的资源,或者修改现有资源。因此,改动升级必不可少,但是,作为平台开发者,应该知道:一旦API
开放出去,有人开始用了,平台的任何改动都需要考虑对当前用户的影响。因此,做开放平台,从第一个API
的设计就需要开始API
的版本控制策略问题,API
的版本控制策略就像是开放平台和平台用户之间的长期协议,其设计的好坏将直接决定用户是否使用该平台,或者说用户在使用之后是否会因为某次版本升级直接弃用该平台。
二、配置
有两种配置方案,一种是在settings
中全局配置,第二种是在视图中指定,不过此方法一般不使用
,因为版本控制大部分情况下是全局的处理情况
2.1、全局配置
settings.py
:
REST_FRAMEWORK = { 'DEFAULT_VERSIONING_CLASS': None, 'DEFAULT_VERSION': None, 'ALLOWED_VERSIONS': None, 'VERSION_PARAM': 'version', }
- DEFAULT_VERSIONING_CLASS:指定版本控制的类,譬如:'rest_framework.versioning.NamespaceVersioning',有多种方式。默认为None,为None时,框架变量request.version将始终返回None
- DEFAULT_VERSION:当版本控制信息不存在时用于设置request.version的默认值,默认设置为None。
- ALLOWED_VERSIONS:允许的版本号,譬如:['v1', 'v2']。区分大小写,如果请求的版本号不在此列表中,抛出错误,上述的 DEFAULT_VERSION 的值必须是列表中的值,None除外
- VERSION_PARAM:版本控制参数的字符串,默认就是version,一般不修改
2.2、视图配置
views.py
# 仅仅指定 版本控制类 class ProfileList(APIView): # 指定 版本控制类 versioning_class = versioning.QueryParameterVersioning
三、drf内置的5个版本控制类
3.1、AcceptHeaderVersioning
基于请求头的版本控制,这种方式也是最推荐的方式
1.http访问方式
GET /bookings/ HTTP/1.1
Host: example.com
Accept: application/json; version=1.0
在上面的示例请求中request.version
属性将返回字符串'1.0'。 基于accept headers
的版本控制通常被认为是最佳实践,尽管其他版本控制方式可能适合你的客户端需求。
2.settings
REST_FRAMEWORK = { 'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.AcceptHeaderVersioning', 'DEFAULT_VERSION': 'v1', 'ALLOWED_VERSIONS': ['v1', 'v2'], }
说明:
- 设置版本控制类为
AcceptHeaderVersioning
- 没有检测到
version
时,默认是v1
版本 - 允许的2个版本型号为:
['v1', 'v2']
3.serializers
class BookSerializer(serializers.ModelSerializer): class Meta: model = BookInfo fields = ['title', 'pub_date', 'read', 'comment', 'image'] class BookSerializerV2(serializers.ModelSerializer): class Meta: model = BookInfo fields = ['title', 'pub_date', 'read', 'comment']
说明:
- 根据不同的版本号,可以对
response
返回内容进行控制,我们设置2个不同的Book
模型的serializer
类对应不同的版本 - 2个序列化类返回的字段不同
BookSerializerV2
的fields
中没有包含image
,那么就应该把属性定义去掉,不然会抛出错误
4.views
class BookView(ListAPIView): queryset = BookInfo.objects.all() serializer_class = BookSerializer def get_serializer_class(self): if self.request.version == "v2": return BookSerializerV2 return self.serializer_class
说明:
- 修改
BookView
类,重载get_serializer_class
方法 - 通过
self.request.version
获取捕获到的版本号进行控制
5.访问
我们在请求头中添加字段Accept:application/json;version=v1
,就会返回BookSerializer
的序列化字段,也就是有image
字段
我们在请求头中添加字段Accept:application/json;version=v2
,就会返回BookSerializerV2
的序列化字段,也就是没有image
字段
3.2、URLPathVersioning
此方案要求客户端将版本指定为URL路径的一部分。
1.http访问方式
GET /v1/bookings/ HTTP/1.1
Host: example.com
Accept: application/json
说明:
版本控制出现在url
路径中,但是具体的这个 v1
出现在哪个部分,取决于url
路由配置中的情况
2.settings
REST_FRAMEWORK = { 'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.URLPathVersioning', 'DEFAULT_VERSION': 'v1', 'ALLOWED_VERSIONS': ['v1', 'v2'], }
3.urls
子应用的urls.py中:
urlpatterns = [ path('<str:version>/books/', views.BookView.as_view()), ]
说明:
设置版本控制在最后,访问url
是类似:http://127.0.0.1:8000/api/v2/books/
4.访问
我们在配置好url
后,在url
中输入v1,就会访问v1版本的接口
在url
中输入v2,就会访问v2版本的接口
3.3、NamespaceVersioning
对于客户端,此方案与URLPathVersioning
相同。唯一的区别是,它是如何在 Django
应用程序中配置的,因为它使用URL conf
中的命名空间而不是URL conf
中的关键字参数。
使用此方案,request.version
属性是根据与传入请求的路径匹配的 namespace
确定的。
如果你只需要一个简单的版本控制方案URLPathVersioning
和NamespaceVersioning
都是合适的。URLPathVersioning
这种方法可能更适合小型项目,对于更大的项目来说NamespaceVersioning
可能更容易管理。
1.http访问方式
GET v1/something/ HTTP/1.1
Host: example.com
2.settings
REST_FRAMEWORK = { 'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.NamespaceVersioning', 'DEFAULT_VERSION': 'v1', 'ALLOWED_VERSIONS': ['v1', 'v2'], }
3.urls
根urls.py中:
urlpatterns = [ path('v1/api/', include('api.urls', namespace='v1')), path('v2/api/', include('api.urls', namespace='v2')), ]
说明:
增加了2个v1
和v2
的不同的路由配置
4.访问
访问v1
版本
访问v2
版本
其余HostNameVersioning
和QueryParameterVersioning
用的不多,想了解的可以查询官方文档
以上就是浅析Django接口版本控制的详细内容,更多关于Django接口版本控制的资料请关注我们其它相关文章!