从源更新

API 规范是活的。重新导入并覆盖一切会丢失您的调整；另开一份导入则会产生重复。Restorm 选择第三条路：计算差异。

工作原理

每次成功的导入都会在所创建的环境文件夹上记录一份源的指纹。文件夹的刷新按钮 会重新获取源、比较指纹，并应用差异，而不是从零重来：

• 新操作会被添加到一次全新导入会放置的位置；
• 有变化的操作会用规范新增的内容补全其参数；
• 被规范标记为已弃用的操作会被标示，并在树中显示为灰显；
• 从源中消失的操作会被标示为已移除，并显示为删除线 —— 它们仍可执行，且绝不 会被删除；
• 您的修改会被保留：名称、请求方法、URL 和已填入的取值绝不会被覆盖。

原则是：规范对它所描述的内容有决定权，其余部分由您决定。

完整流程 —— 按钮在哪里、应用之前向导显示什么、文档会发生什么 —— 详见 访问并更新已导入 API 的文档。

仅适用于通过 URL 的导入

重新同步的前提是 Restorm 知道源在哪里。只有从一个 URL 完成的导入才会记录源； 从文件导入或粘贴导入无法重新同步，即使其格式出现在下面的清单中。

可重新同步的格式

涉及十二种格式：

• OpenAPI 3.x
• Swagger 2.0 （与上一项同一页面，但这里单独计数：两者各有自己的重新同步逻辑）
• GraphQL（SDL）
• gRPC —— .proto 文件和服务端 reflection
• SOAP / WSDL
• OData
• AsyncAPI
• Postman
• Insomnia
• Bruno
• OpenRPC
• Smithy

不可重新同步的格式

HAR、cURL、 PowerShell、 REST Client、 Thunder Client、 Paw、HTTPie、 RAML、WADL、 Thrift、TypeSpec、 API Blueprint、 tRPC。

对于这些格式，一次新的导入会创建一棵新的树：需要您自己去对照两者，或者导入到一个 专用文件夹中。

特例：通过 reflection 导入的 gRPC

通过 reflection 导入的 gRPC 请求，其标签页上直接带有一个从 reflection 刷新按钮： 当某个服务在开发过程中不断变化时，这是最短的路径。