Apicurio-studio: 尝试从 github 打开现有模型时出现页面未找到错误。

您好，感谢您的反馈。 不幸的是，现在 Apicurio 不支持读/写 YAML（如您所见）。 这里有一个功能请求：

https://github.com/Apicurio/apicurio-studio/issues/165

这并不难做到，但在队列中的那个之前还有一些其他的增强。 :)

作为一种解决方法，您可以尝试从 YAML 转换为 JSON，将结果存储在 GitHub 中，然后打开它。 我知道这很烦人，但是在我们可以将附加功能添加到 apicurio 之前，这会起作用。

注意：这仍然是一个有效的错误报告，因为我们在添加/导入 API 时需要更好的错误消息。 如果找不到资源（例如从 URL 导入时），那么我们应该报告（而不是报告“找不到页面”错误）。 如果资源存在但格式不正确，我们应该以不同的方式报告。

我今天无法使用我的 OpenAPI 3 JSON 或上面链接的示例。 从 URL 导入不适用于：

https://github.com/Apicurio/apicurio-studio/blob/master/back-end/hub-api/src/test/resources/io/apicurio/hub/api/beans/simple-api-3.0.json

或者

https://github.com/david4096/data-object-schemas/blob/openapi3/openapi/data_objects_service.openapi.json

嗨@david4096 - 第一个 URL 失败，因为该 URL 上确实没有任何内容。 至少当我点击那个链接时没有文件。 实际上，该模块在src/test没有resources文件夹：

https://github.com/Apicurio/apicurio-studio/tree/master/back-end/hub-api/src/test

然而，在第二URL明显的内容。 它在 Apicurio 中不起作用的原因是不幸的是，我们还不支持从分支（仅主）中提取内容。 这显然缺少功能，因为支持分支并不困难。

也就是说，我认为我们正朝着能够从任意 URL 添加/导入 API 设计的方向前进，而不是通过各自的 API 从各种源代码控制系统添加/导入 API 设计（这就是我们现在所做的，纯粹是作为保留从我们更加依赖这些系统来存储数据的时候开始）。 我将提高“从 URL 导入”功能的优先级，并将其包含在下一个版本中。

目前，您可以做的解决方法是将您想要添加/导入的任何 API 存储到任何 github 存储库的主分支（可能为此目的创建一个存储库）并从那里导入。

我添加了一张票来支持源代码管理中的分支：

https://github.com/Apicurio/apicurio-studio/issues/222

但是我认为从任意 URL 导入内容将是一个更有用的功能，所以我将首先解决这个问题。

嗨@EricWittmann感谢您的解释！