DRF框架API版本管理实现方法解析

urlpatterns = [
  url(
    r'^("htmlcode">

settings/common.py
REST_FRAMEWORK = {
  'DEFAULT_VERSIONING_CLASS': 'rest_framework.versioning.NamespaceVersioning',
  'DEFAULT_VERSION': 'v1'
}


以上两项设置分别全局指定使用的 API 版本管理方式和客户端缺省版本号的情况下默认请求的 API 版本。尽管这些配置项也可以在单个视图或者视图集的范围内指定，但是，统一的版本管理模式更为可取，因此我们在全局配置中指定。
接着在注册的 API 接口前带上版本号：


blogproject/urls.py
urlpatterns = [
  # ...
  path("api/v1/", include((router.urls, "api"), namespace="v1")),
]


注意这里比之前多了个 namespace 参数，参数值为 v1，代表包含的 URL 模式均属于 v1 这个命名空间。还有一点需要注意，对于 include 函数，如果指定了 namespace 的值，第一个参数必须是一个元组，形式为：(url_patterns, app_name)，这里我们将 app_name 指定为 api。
一旦我们开启了版本管理，所有请求对象 request 就会多出一个属性 version，其值为用户请求的版本号（如果没有指定，就为默认的 DEFAULT_VERSION 的值）。因此，我们可以在请求中针对不同版本的请求执行不同的代码逻辑。比如我们的博客修改文章列表 API，序列化器对返回数据的字段做了一些改动，发布在版本 v2，那么可以根据用户用户请求的版本，返回不同的数据，即新增了 API，又保持对原 api 的兼容：


if request.version == 'v1':
	return PostSerializerV1()
return PostSerializer


if 分支可以视为一段临时代码，我们可以通过适当的方式提醒用户，API 已经更改，请尽快迁移到新的版本 v2，并且在未来的某个时间，确认大部分用户都成功迁移到新版api后移除掉这些代码，并将默认版本设为v2，这样原本的 v1 版本的 API 就彻底被废弃了。
当然，我们目前的博客接口还暂时没有需要修改升级的地方，不过为了测试 API 版本管理的设置是否生效了，我们认为添加一个测试用的视图集，在里面做针对不同版本请求的处理，看看不同版本的请求下是否会返回符合预期的不同内容。
首先在 blog/views.py 中加一个简单的测试视图集，这个视图集中有个测试用的接口，接口处理逻辑是根据不同的版本号，返回不同的内容：


class ApiVersionTestViewSet(viewsets.ViewSet):
  @action(
    methods=["GET"], detail=False, url_path="test", url_name="test",
  )
  def test(self, request, *args, **kwargs):
    if request.version == "v1":
      return Response(
        data={
          "version": request.version,
          "warning": "该接口的 v1 版本已废弃，请尽快迁移至 v2 版本",
        }
      )
    return Response(data={"version": request.version})


当然视图集别忘了在 router 中注册：
blogproject/urls.py


blogproject/urls.py

# 仅用于 API 版本管理测试
router.register(
  r"api-version", blog.views.ApiVersionTestViewSet, basename="api-version"
)


这相当于一次接口版本升级，我们再加入 v2 命名空间的接口：


urlpatterns = [
  path("api/v1/", include((router.urls, "api"), namespace="v1")),
  path("api/v2/", include((router.urls, "api"), namespace="v2")),
]


可以看到，包含的 URL 都是一样的，只是 namespace 是 v2。
来测试一下效果，启动开发服务器，先访问版本号为 v1 的测试接口，请求返回结果如下，可以看到如期返回了 v1 版本下的内容：


GET /api/v1/api-version/test/
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept
{
  "version": "v1",
  "warning": "该接口的 v1 版本已废弃，请尽快迁移至 v2 版本"
}


再访问版本号为 v2 的测试接口，返回的内容就是 v2 了。


GET /api/v2/api-version/test/

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
  "version": "v2"
}


对于其它接口，无论 v1，v2 版本的接口均可以访问，这样就相当于完成了一次兼容的接口升级。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。