我遇到的问题是,我有一些替代方案和理论的想法,虽然我真的不知道哪一个是最好的选择。
问题描述我有一个足够大的Postman API集合,包含20-30个供应商API。它是基于每个供应商的公共规范的各种OpenAPI导入构建的,对于一些人来说,它是基于他们的.DOC或.PDF文档的手动集合编写的。它已经积累了2年,我们的Postman集合。
我开始做一个内部项目,一个Ruby on Rails API,需要与这20-30个供应商进行通信,为了与他们集成,我必须手动编写API适配器层,MapPostman的测试和示例。我使用RestClient Ruby gem。
为了保存这个过程的时间,我一直在想一种方法来改善这种开发体验,并最终节省一些时间。
我能想到的选择我想到的选择:
1.或者手动将Postman Library导出为OpenAPI JSON,按供应商,按集合,并使用20-30个结果JSON文件中的每个作为OpenAPI Code Generator的输入。
1.关于手动导出部分,也许有一种方法可以通过使用PostmanCollectionRunner或纽曼使其自动化
1.关于JSON文件,我相信代码生成器可以使用YAML,也许我需要一个JSON -〉YAML转换器
1.为了使Postman与RailsRestClient适配器层保持同步,我想也许可以构建某种管道,以便当集合中发生更改时触发一个作业来获取其代码
1.为了将Postman作为一种微服务来使用,开发,配置供应商API库,然后将Rails服务与一种Rails gem Postman REST客户端适配器连接起来,并希望有一些自动完成。
1.导出并迁移整个Postman集合到一种API聚合器工具。任何建议都可能有所帮助。然后使用Rails连接到该工具。
希望这有一定的意义,希望我没有问太多的细节。如果你知道任何这样的项目或参考,这可能会有所帮助。
1条答案
按热度按时间n6lpvg4x1#
根据20-30个模式的组成,我建议选择4:将openapi-merge与openapi-generator一起使用
我假设这20-30个API都是第三方的,这意味着你无法控制它们。这很好。将它们从postman导出到各自的json文件中。将它们添加到
openapi-merge
中以创建一个巨大的openapi规范。使用openapi-generator
的新规范来生成代码。优点:
openapi-merge
在发生冲突时使用第一个输入规范作为默认值。这允许您定义一个单独的文件,其中包含您自己的自定义信息,服务器,标签等。openapi-generator
强制执行API first编码方法。这确保您的代码始终与第三方API的模式匹配。openapi-generator
会把你的json转换成yaml。没有附加字符串。1.我相信你已经知道,
openapi-generator
是非常可定制的。你可以通过mustache模板定制生成的文件,或者用你自己的生成器定制生成器本身。它支持多种语言和配置,可以生成一个开箱即用的工作服务器。缺点:
1.因为
openapi-merge
通过FIFO方法解决冲突,所以如果任何模式具有冲突的对象名称或参数,它们将被覆盖。