ソースから更新する

API の仕様書は変化していきます。すべて上書きして再インポートすれば手を加えた部分が失われ、別の場所に再インポートすれば重複ができてしまいます。Restorm は第三の方法を取ります。差分を計算するのです。

仕組み

インポートが成功するたびに、作成された変数フォルダーにソースのフィンガープリントが記録されます。フォルダーの 更新 ボタンはソースを取得してフィンガープリントを比較し、ゼロから作り直すのではなく差分だけを適用します。

• 新しい操作は、新規インポートであれば配置されたはずの場所に追加されます。
• 変更された操作には、仕様書が追加したパラメーターが補われます。
• 仕様書が非推奨と示した操作には印が付き、ツリー上で淡色表示になります。
• ソースから消えた操作は削除済みとして印が付き、取り消し線付きで表示されます。実行は引き続き可能で、削除されることはありません。
• こちらで加えた変更は保持されます。名前、メソッド、URL、入力した値が上書きされることはありません。

原則はこうです。仕様書は自身が記述する範囲について権威を持ち、それ以外については利用者側に決定権があります。

ボタンの場所、適用前にウィザードが表示する内容、ドキュメントがどう扱われるかといった一連の流れは、インポートした API のドキュメントの参照と更新で解説しています。

URL 経由でインポートした場合のみ

再同期は Restorm がソースを把握していることを前提とします。ソースが記録されるのは URL から行ったインポートだけです。ファイルからのインポートや貼り付けによるインポートは、たとえその形式が下記の一覧に含まれていても再同期できません。

再同期できる形式

対象となるのは 12 形式です。

• 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。

これらの形式では、あらためてインポートすると新しいツリーが作成されます。2 つを突き合わせるか、専用のフォルダーにインポートするかは、こちらで判断してください。

特殊なケース：reflection 経由の gRPC

reflection でインポートした gRPC リクエストには、そのタブ上に直接 reflection から更新 ボタンが表示されます。開発中にサービスが変化していく場面では、これがもっとも短い経路です。