我是您所提及问题的被采纳答案的作者。我认为像您说的那样使用/<version>/users
方法并不是非常有效。如果你必须管理三个或四个不同版本,最终会得到混乱的代码。
我在那里提出的nginx方案更好,但缺点是必须托管两个独立的应用程序。当时我错过了第三种选择,即为每个API版本使用一个蓝图。例如,请考虑以下应用程序结构(为清晰起见大大简化):
my_project
+-- api/
+-- v1/
+-- __init__.py
+-- routes.py
+-- v1_1/
+-- __init__.py
+-- routes.py
+-- v2/
+-- __init__.py
+-- routes.py
+-- __init__.py
+-- common.py
这里有一个 api/common.py
,它实现了所有版本API所需的公共功能。例如,您可以拥有一个辅助函数(未装饰为路由),响应于您的/users
路由,并在v1和v1.1中完全相同。
每个API版本的routes.py
定义了路由,必要时调用common.py
函数以避免重复逻辑。例如,您的v1和v1.1 routes.py
可能包含如下内容:
from api import common
@api.route('/users')
def get_users():
return common.get_users()
请注意api.route
。这里的api
是蓝图。将每个API版本实现为蓝图有助于将所有内容与正确版本的URL相结合。下面是一个示例应用设置代码,将API蓝图导入到应用程序实例中:
from api.v1 import api as api_v1
from api.v1_1 import api as api_v1_1
from api.v2 import api as api_v2
app.register_blueprint(api_v1, url_prefix='/v1')
app.register_blueprint(api_v1_1, url_prefix='/v1.1')
app.register_blueprint(api_v2, url_prefix='/v2')
这种结构非常好,因为它将所有API版本分开,但它们由同一个应用程序提供。作为附加好处,当停止支持v1时,只需删除该版本的register_blueprint
调用,从源中删除v1
包,就完成了。
现在,我们需要尽力以一种最小化必须更新版本的风险的方式设计API。请注意,添加新路由不需要新的API版本,使用新路由扩展API是完全可以的。而对现有路由的更改有时可以设计成不影响旧客户端的方式。有时更新API并具有更多自由更改事物会更容易,但理想情况下,这种情况不应经常发生。
__init__.py
文件中创建的。 - Miguel Grinberg