请帮忙！
我是Swagger的新手，写烧瓶API。我们仍在研究最佳实践，因此我需要使用蓝图和swag_from创建一些路线：
from flasgger import swag_from
虽然我还有另一条使用BluePrint和blusk_restx软件包的路线，并且其中包含get（）和post（）方法。
结果，我的宣传文档分配在两个不同的页面之间：
a） http：// http：//127.0.0.0.1:5000 /apidocs/ - 用于使用蓝图和swag_from的路由
b）我的API的根URL-对于使用blask_restx的端点，
我想将这两个摇摇欲坠的页面合并到一个宣传页面中。有办法做到吗？通常，在使用上述不同的包装编写不同的路线时，通常可以这样做吗？
多谢！任何关于如何做到这一点的指示都将不胜感激！
Please help!
I am new to Swagger and to writing flask APIs. We are still researching the best practices, so I needed to create some routes using Blueprint and swag_from:
from flasgger import swag_from
While i have one other route that is using Blueprint and flask_restx package and has get() and post() methods in it.
As a result, my swagger documentation is split between two different pages:
a) http://127.0.0.1:5000/apidocs/ - for routes using Blueprint and swag_from
b) my Api's root url - for the endpoint that's using flask_restx
I want to merge these two swagger pages into a single swagger page. Is there a way to do it? And is it generally possible to do this while having different routes written using different packages as described above?
Thanks a lot! Any pointers on how to this best would be much appreciated!
发布评论
评论（1）
两个提到的框架都创建了内部数据结构，以维护OpenAPI规格生成的数据。这些内部数据结构不能以任何简单的编程方式合并。
除了非常特殊的情况（某些软件包是通过设计合作的，例如Flasgger+烧瓶，）通常不可能将多个解决方案合并为一种。
您也可以完全解开式OpenAPI规格文档，并独自发布规格，无论其背景如何处理哪种包裹，都可以为所有路线发布。
由于其余API世界没有太多的标准化，因此很难指出任何真正最佳实践。我会坚持一般的经验法则“保持简单，保持安全”，然后仅使用一种解决方案。
另外，您可以研究可用的其他库和框架，并找到满足所有项目要求的第三选项。
specs_route配置选项doc doc doc/代码>参数Both mentioned frameworks creates internal data structures in order to maintain data for OpenAPI spec generation. Those internal data structures cannot be merged in any easy programmatic way.
Except very special cases (some packages are meant to work together by design, eg. flasgger+flask-restful) it is not generally possible to combine multiple solutions into one.
You can alternatively fully un-bundle OpenAPI specs documentation and publish specs by yourself for all routes no matter how or by which package they gets handled on the background.
It's hard to point at any really best practice since there is not much standardization in the REST API world. I would stick to the general rule of thumb "keep it simple, keep it safe" and stick only with one solution.
Alternatively you might research other libraries and frameworks available and find 3rd option which would satisfy all project requirements.
specs_routeconfiguration optionsdocparameter