如何在Django Rest Framework(DRF)中实现移动应用API版本控制

你当前在URL路径中嵌入版本号的实现是行业主流的基础方案，在此基础上要满足「数据库修改不影响旧版移动应用」的需求，还需要遵循以下规范：

• 接口层严格保持兼容：每个版本接口对外暴露的请求参数、响应字段结构永久保持不变。数据库新增字段时，旧版本接口的响应直接忽略新增字段；需要修改/删除旧字段时，禁止直接操作原有字段，必须新增字段供新版本接口使用，旧版本接口依然映射原有字段返回数据，不关联任何新增的数据库逻辑。
• 代码完全独立拆分：你当前的路由拆分方式是合理的，建议继续保持不同版本的路由文件、业务逻辑代码、数据序列化层完全隔离，禁止在新版本代码中修改旧版本接口的逻辑，避免出现关联影响。路由配置保持类似现有写法即可：

path('v1/auth/', include('authentication.urls')),
path('v2/auth/', include('authentication.urls2')), # Example
path('v1/api/', include('contentstudio.urls')),

• 数据库变更遵守兼容规则：所有数据库结构变更优先做兼容处理，新增字段必须设置默认值或允许为空，禁止给旧版本接口用到的表新增非空且无默认值的字段，避免旧版本写入数据时报错。旧字段的删除必须等到对应旧版本API的用户渗透率降至0之后再执行。
• 版本迭代规则明确：只有出现不兼容变更（如请求参数调整、响应字段删减、核心业务逻辑变更）时才升级大版本号，小功能迭代、bug修复不要随意升大版本，避免版本数量过多增加维护成本。
• 废弃版本提前通知：对计划下线的旧版本，提前在对应接口的响应头中添加废弃标识，同时在APP内推送升级通知，确认用户完全迁移后再下线对应版本的接口和旧数据库字段。

如果希望版本号不暴露在URL中，也可以选择将版本号放在请求头中传递，但路径版本号的方式更直观，排查问题更方便，更适配移动应用的使用场景。

内容的提问来源于stack exchange，提问作者Sanjay Sikdar