一、前言
在 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
基于请求头的版本控制，这种方式也是最推荐的方式
3.1.1、http访问方式GET /bookings/ HTTP/1.1
Host: example测试数据
Accept: application/json; version=1.0
在上面的示例请求中 request.version 属性将返回字符串'1.0'。 基于 accept headers 的版本控制通常被认为是最佳实践，尽管其他版本控制方式可能适合你的客户端需求。
3.1.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.1.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个序列化类返回的字段不同 SmWKTV BookSerializerV2 的 fields 中没有包含 image ，那么就应该把属性定义去掉，不然会抛出错误 3.1.4、views
class BookView(ListAPIView):
queryset = BookInfo.objects.all()
serializer_class = BookSerializer
def get_serializer_class(self):
if self.req 编程客栈 uest.version == "v2":
return BookSerializerV2
return self.serializer_class
说明：
修改 BookView 类，重载 get_serializer_class 方法 通过 self.request.version 获取捕获到的版本号进行控制 3.1.5、访问我们在请求头中添加字段 Accept:application/json;version=v1 ，就会返回 BookSerializer 的序列化字段，也就是有 image 字段
我们在请求头中添加字段 Accept:application/json;version=v2 ，就会 http://HdhCmsTestcppcns测试数据 返回 BookSerializerV2 的序列化字段，也就是没有 image 字段
3.2、URLPathVersioning
此方案要求客户端将版本指定为URL路径的一部分。
3.2.1、http访问方式GET /v1/bookings/ HTTP/1.1
Host: example测试数据
Accept: application/json
说明：
版本控制出现在 url 路径中，但是具体的这个 v1 出现在哪个部分，取决于 url 路由配置中的情况
3.2.2、settings
REST_FRAMEWORK = {
'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.URLPathVersioning',
'DEFAULT_VERSION': 'v1',
'ALLOWED_VERSIONS': ['v1', 'v2'],
}
3.2.3、urls
子应用的urls.py中：
urlpatterns = [
path('<str:version>/books/', views.BookView.as_view()),
]
说明：
设置版本控制在最后，访问 url 是类似： http://127.0.0.1:8000/api/v2/books/
3.2.4、访问我们在配置好 url 后，在 url 中输入v1，就会访问v1版本的接口
在 url 中输入v2，就会访问v2版本的接口
3.3、NamespaceVersioning
对于客户端，此方案与 URLPathVersioning 相同。唯一的区别是，它是如何在 Django 应用程序中配置的，因为它使用 URL conf 中的命名空间而不是 URL conf 中的关键字参数。
使用此方案， request.version 属性是根据与传入请求的路径匹配的 namespace 确定的。
如果你只需要一个简单的版本控制方案 URLPathVersioning 和 NamespaceVersioning 都是合适的。 URLPathVersioning 这种方法可能更适合小型项目，对于更大的项目来说 NamespaceVersioning 可能更容易管理。
3.3.1、http访问方式GET v1/something/ HTTP/1.1
Host: example测试数据
3.3.2、settings
REST_FRAMEWORK = {
'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.NamespaceVersioning',
'DEFAULT_VERSION': 'v1',
'ALLOWED_VERSIONS': ['v1编程客栈', 'v2'],
}
3.3.3、urls
根urls.py中：
urlpatterns = [
path('v1/api/', include('api.urls', namespace='v1')),
path('v2/api/', include('api.urls', namespace='v2')),
]
说明：
增加了2个 v1 和 v2 的不同的路由配置
3.3.4、访问访问 v1 版本
访问 v2 版本
其余 HostNameVersioning 和 QueryParameterSmWKTVVersioning 用的不多，想了解的可以查询官方文档
以上就是浅析Django接口版本控制的详细内容，更多关于Django接口版本控制的资料请关注我们其它相关文章！