浅析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个版本本文来源gao($daima.com搞@代@#码(网控制类

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']

喜欢 (0)赏

[搞代码]

分享 (0)