首页 > 解决方案 > 动态生成 Flask-RESTPlus 路由

问题描述

我正在尝试抽象出一些路由类逻辑(即我希望动态生成路由)。 api.add_resource似乎是做这件事的正确地方。

所以这就是我想要做的:

# app.py

from flask import Flask
from flask_restplus import Api, Resource, fields
from mylib import MyPost

# Define my model
json_model = api.schema_model(...)

api.add_resource(
    MyPost,
    '/acme',
    resource_class_kwargs={"json_model": json_model}
)

然后在 mylib 中:

# mylib.py

def validate_endpoint(f):
    def wrapper(*args, **kwargs):
        return api.expect(json_fprint)(f(*args, **kwargs))
    return wrapper

class MyPost(Resource):
    def __init__(self, *args, **kwargs):
        # Passed in via api.add_resource
        self.api = args[0]
        self.json_model = kwargs['json_model']

    # I can't do this because I don't have access to 'api' here...
    # @api.expect(json_model)

    # So I am trying to make this work
    @validate_endpoint
    def post(self):
        return {"data":'some data'}, 200

我在这里无权访问全局 api 对象,因此无法调用@api.expect(json_model). 但我确实可以访问apijson_model在 post 方法内部。这就是我尝试创建自己的validate_endpoint装饰器的原因。

但这不起作用。我在这里尝试做的甚至可能吗?我应该采取更好的方法吗?

标签: flask-restplus

解决方案


停止使用 flask-restplus。这是我能给你(和其他任何人)最有价值的答案。

所有权不存在

Flask-restplus 是 flask-restful 的一个分支。一些工程师开始开发适合他们的功能。核心人物已经隐藏了该项目,因此它再次被正式分叉为 Flask-Restx。

设计不佳

我小时候很喜欢烧瓶。从那时起,我意识到拥有所有神奇更新的全局请求、应用程序和配置并不是一个好的设计。他们的应用程序工厂模式(flask-restplus 符合)是一种有状态地改变应用程序对象的风格。首先,它很难测试。其次,这意味着 flask-restplus 正在包装应用程序以及所有请求/处理程序。怎么会有人认为那是一件好事?一个以端点文档为主要功能的库,我的每一个请求都被它肮脏的手弄脏了??(顺便说一句,这是导致您上述问题的原因)因为我的帖子是严肃而深思熟虑的,所以我跳过了对 Resource 类模式的想法,因为它可能会将我推入咆哮的水域。

随机特征集

一个好的图书馆有一个单一的目的,而且它做得很好。Flask-restplus 做了 15 件事(掩码、swagger 生成、邮递员生成、编组、请求 arg 验证)。通过阅读文档,您甚至无法分辨的一些功能在库代码中。

我对您问题的解决方案

如果你想通过函数装饰器和模型来记录你的代码,请使用一个单独完成并且做得很好的工具。使用不会触及您的处理程序或影响您的实际请求装饰器的一种。使用oapispec进行大摇大摆的生成。对于 flask-restplus 的其他特性,你有marshmallow用于编组请求/响应数据,pydantic用于验证请求对象和 args,等等。

顺便说一句,我知道这一切,因为我必须用它构建一个 api。在与框架进行了数周的斗争后,我将其分叉、拆开、创建了 oapispec,然后将其从项目中删除。


推荐阅读