StoplightからApidogへの移行は、単にOpenAPIファイルをインポートすることだけではありません。それはファイルベースのAPIワークフローを移行することです。
多くのチームにとって、Stoplightプロジェクトにはエンドポイント以上のものが含まれていました。Git内のOpenAPI仕様、Markdownドキュメント、JSONスキーマモデル、ローカル画像、サポートされているtoc.jsonナビゲーション入力、およびサポートされている.stoplight.jsonパス設定などです。
チームはPostmanにリクエスト例を、CIにテストスクリプトを持っている場合もあります。StoplightからApidogへの移行が1つのOpenAPIファイルしかインポートしない場合、エンドポイントリストは残るかもしれませんが、ワークフローは残りません。
Apidog Spec-firstモードは、Stoplightからの移行中にOpenAPIファイルを唯一の信頼できる情報源として維持しながら、それらのファイルをドキュメント、モック、テスト、レポート、権限、共同作業のためのより広範なAPIワークスペースに接続するのに役立ちます。
このガイドでは、その移行を計画する方法、つまり何を引き継ぐことができ、何をレビューすべきか、何を再構築する必要があるか、そしてOpenAPI契約の周りに何を接続すべきかを説明します。
操作上のセットアップ手順については、Spec-firstモードヘルプガイドを参照してください。
Stoplightからの移行がOpenAPIのインポート以上の意味を持つ理由
OpenAPIファイルはAPI契約を記述します。Stoplightスタイルのプロジェクトは通常、その契約に関するより多くのコンテキストを含んでいます。
一般的なプロジェクトアセットには以下が含まれます。
- OpenAPIまたはSwaggerファイル（多くの場合、
referenceまたは別の構成されたディレクトリに保存されます）。 - Markdownドキュメント（多くの場合、
docsに保存されます）。 - JSONスキーマモデルファイル（多くの場合、
modelsに保存されます）。 - ドキュメントによって参照されるローカル画像。
- サポートされているパス構成のための
.stoplight.json。 - サポートされているドキュメントナビゲーション入力、グループ化、および順序付けのための
toc.json。 x-stoplight-idやx-stoplight.idのようなStoplight識別子。
移行が1つのOpenAPIファイルしかインポートしない場合、エンドポイントは移行されるかもしれませんが、プロジェクトモデルは失われる可能性があります。ドキュメントは再構築が必要になるかもしれません。ナビゲーションは以前のプロジェクトと一致しないかもしれません。モデルはドキュメントから切断されるかもしれません。テスト、モック、リクエスト例は、依然として別々のツールに残るかもしれません。
より良い移行計画は、単一の仕様ファイルからではなく、リポジトリまたはファイルツリーから開始されます。
移行モデル：引き継ぎ、レビュー、再構築、接続
開始する前に、真の信頼できる情報源を特定してください。Git内のOpenAPIファイルがAPI契約を定義している場合、Spec-first移行はそのファイルから開始できます。PostmanまたはBrunoコレクションが実際のリクエストワークフローを推進している場合、まずその不一致を解消してください。
最も強力な移行計画は「すべてを保持する」ことではありません。Stoplightプロジェクトには、他のワークスペースに1対1でマッピングできない製品固有の動作が含まれている場合があります。
代わりに、以下の4つの部分からなるモデルを使用してください。
| カテゴリ | 何が含まれるか | 移行の方針 |
|---|---|---|
| 引き継ぎ | OpenAPIファイル、サポートされている.stoplight.jsonパス設定、サポートされているtoc.jsonナビゲーション入力、Markdownドキュメント、参照されているローカル画像、およびサポートされているJSONスキーマモデル。 | ファイルベースのプロジェクトコンテキストをSpec-firstモードに取り込みます。 |
| レビュー | Markdownリンク、アンカー、画像、TOCグループ化、スキーマ命名、外部$ref、Stoplight ID、生成されたページ、およびレンダリングの違い。 | 移行されたワークスペースを本番環境対応として扱う前に検証します。 |
| 再構築 | PostmanまたはBrunoのリクエストフロー、環境、手動テスト、モック、CIジョブ、および仕様プロジェクトの外にあった場合の公開ルール。 | これらをOpenAPIの唯一の信頼できる情報源の周りに再作成します。 |
| 接続 | APIドキュメント、モックAPI、テスト、CIレポート、権限、チームコラボレーション、およびパートナー向けワークフロー。 | Apidogを使用して、APIライフサイクル全体で契約を役立つものにします。 |
この区別が重要であるのは、Stoplightの移行には2つのレイヤーがあるためです。
最初のレイヤーはファイルレイヤーです。OpenAPI仕様、Markdownドキュメント、モデルファイル、画像、およびプロジェクト構造ファイルが含まれます。これはSpec-firstモードが最も直接的に役立つ部分です。
2番目のレイヤーはワークフローレイヤーです。チームがAPIの変更をレビューし、ドキュメントを公開し、テストを実行し、モックを管理し、レポートを共有し、バックエンド、フロントエンド、QA、製品、パートナーチームと共同作業を行う方法です。このレイヤーはインポートの副産物として扱われるべきではありません。Apidogが契約をAPIライフサイクルの残りの部分に接続できるのはここです。
Apidog Spec-firstモードがStoplightプロジェクトにどのように適合するか
ApidogのSpec-firstモードは、ファイルベースのワークフローのために構築されています。これはまさにあなたのStoplightプロジェクトがすでに使用しているものです。
Git接続プロジェクトは、リポジトリを中心とします。あなたのブランチは信頼できる情報源として残り、Apidogはそれと同期します。
ファイルバックアッププロジェクトでは、まずApidogで直接仕様ファイルを操作できます。準備ができたら後でGitを接続できます。
仕様ワークスペースは、ソースファイルを管理し、解析されたAPI構造を確認し、すべての編集ワークフローを処理するための1つの場所を提供します。
各タイプのStoplightアセットがApidogでどのように機能するかを以下に示します。
| Stoplightアセット | Apidogでの挙動 | レビュー時の注意点 |
|---|---|---|
| OpenAPI / Swaggerファイル | APIモジュール、エンドポイント、スキーマ、および例としてインポートおよび同期できます。 | バンドルされた参照、変換警告、モジュール命名、およびエンドポイントのグループ化を確認します。 |
.stoplight.json | サポートされているフィールドは、ApidogがOpenAPI、Markdown、JSONスキーマのルートを見つけ、OpenAPIのインクルードパターン、グローバルな除外パターンを適用し、tocPathを解決するのに役立ちます。 | 同期のためのパス検出として扱い、完全なStoplightプロジェクト構成として扱わないでください。すべてのStoplight formats設定やプロジェクトの動作が同じように適用されるとは限りません。 |
toc.json | Apidogがサポートされているグループや区切りからDOCSフォルダを作成し、TOCにリストされたMarkdownドキュメントをフィルタリングおよび順序付けし、TOCタイトルを適用し、DOCSフォルダをインポートされたOASモジュールまたは選択された仕様項目にリンクし、サポートされている場合はTOCで参照されているJSONスキーマモデルをインポートするのに役立ちます。 | インポート後、最終的なApidogのサイドバーを確認してください。最終的な構造はApidogのDOCS/OAS/MODELSモデルを通じてレンダリングされるため、正確なStoplightナビゲーションや任意のクロスタイプ順序は保持されない場合があります。 |
| Markdownドキュメント | Markdownドキュメントはプロジェクトワークフローに取り込むことができます。TOCにリストされたドキュメントは、サポートされている場合、より多くの構造を保持できます。 | 内部リンク、アンカー、書式設定、欠落しているファイル、およびレンダリングの違いを確認します。 |
| ローカル画像 | Markdownによって参照されるローカル画像は、サポートされている場合、インポートできます。 | 壊れた参照、外部画像、データURI、およびドキュメントによって参照されていない画像を確認します。画像ルート設定をアセットライブラリのインポート保証として扱わないでください。 |
| JSONスキーマモデル | toc.jsonなどのサポートされているプロジェクト構造によって明示的に参照されているJSONスキーマファイルは、サポートされている場合、モデルに取り込むことができます。 | スキーマのフォーマット、命名、グループ化、参照、およびすべてのモデルをインポートすべきかどうかを確認します。 |
| Stoplight ID | ルートレベルのStoplight IDは、Apidogが同期時にインポートされたモジュールを照合するのに役立つ場合があります。 | エンドポイントレベルまたはページレベルのIDが完全に保持されるとは限りません。 |
Stoplightプロジェクトファイルの互換性に関する注意点
.stoplight.jsonは、同期のためのサポートされているパス構成のサブセットとして扱われるべきです。Apidogは、OpenAPI、Markdown、JSONスキーマのサポートされているルートディレクトリ、OpenAPIのインクルードパターン、グローバルな除外パターン、およびtocPathを使用できます。その他のStoplightプロジェクト設定は、検証されない限り無視されるものとして扱われるべきです。toc.jsonは、DOCSフォルダ、Markdownの順序付け、OAS/モジュールリンク、選択された仕様項目リンク、およびTOC参照モデルのインポートを含む、Apidogでサポートされているナビゲーションセマンティクスを再構築するのに役立ちます。最終的なサイドバーは依然としてApidogのDOCS/OAS/MODELSモデルを通じてレンダリングされるため、任意のStoplightレイアウトや正確なクロスタイプ順序は保持されない場合があります。toc.jsonは最終的なオンラインドキュメントサイドバーを完全にカスタマイズするものではありません。- 画像は主にMarkdownによって参照されている場合に移行されます。参照されていないアセット、外部画像、およびデータURIは別途レビューされるべきです。
- JSONスキーマファイルは、ディレクトリからのみ推測されるのではなく、
toc.jsonのようなサポートされているプロジェクト構造によって明示的に参照されている場合に最も予測可能です。
これにより、チームは実用的な出発点を得ることができます。既存のプロジェクトファイルを使用して可能な限り多くのAPIワークスペースを再作成し、その後、Stoplight固有の動作に依存する部分をレビューします。目標は、Stoplightをピクセル単位で再作成することではなく、ポータブルなファイルベースのプロジェクトコンテキストを保持し、それをより広範なAPIライフサイクルに再接続することです。
ファイルインポートから接続されたAPIワークフローへ
従来のインポートワークフローでは、チームはOpenAPIファイルを一度インポートした後、新しいツールで視覚的に作業を続けることがよくあります。これにより乖離が生じる可能性があります。Git内のファイル、ドキュメント、APIワークスペースが、もはや同じ信頼できる情報源を表さなくなる可能性があります。
Spec-firstモードは異なります。ファイルが基盤として残ります。
Git接続されたSpec-firstプロジェクトでは、チームは仕様ワークスペースでファイルを編集し、変更をコミットしてリポジトリにプッシュし直すことができます。ファイルバックアッププロジェクトでは、チームはGitを接続する前にApidog内で仕様ファイルを編集および保存できます。
実用的な区分は以下の通りです。
| 責任 | 推奨される情報源 |
|---|---|
| API契約 | OpenAPI / Swaggerファイル |
| プロジェクトファイル構造 | リポジトリまたはファイルバックアッププロジェクトツリー |
| サポートされているStoplightスタイルのパス設定 | .stoplight.json |
| サポートされているドキュメントナビゲーション入力 | toc.jsonとMarkdownドキュメント |
| 日常のAPI共同作業 | Apidogプロジェクトワークスペース |
| モック、テスト、レポート、およびチーム権限 | より広範なApidogプラットフォームワークフロー |
これが移行の核となる価値です。チームはファイルファーストの契約モデルを維持しながら、より多くの利害関係者にその契約を中心とした利用可能なAPIワークスペースを提供できます。
それがデータ移動とワークフロー移動の違いです。ファイルをインポートすると契約は一度移動します。Spec-firstプロジェクトを接続すると、チームはその契約を中心としたワークスペースを得られます。
Git接続型とファイルバックアップ型移行パス
Stoplightのチームがすべて同じワークフローの成熟度から始まるわけではありません。
一部のチームはすでにGitブランチとプルリクエストを通じてすべてのAPI変更をレビューしています。他のチームはAPI仕様とドキュメントをファイルとして持っていますが、最初の展開で外部のGitプロバイダーを導入する準備ができていません。
Apidog Spec-firstモードは両方のパスをサポートしています。
| パス | 最適な用途 | 一般的なワークフロー |
|---|---|---|
| Git接続型Spec-firstプロジェクト | GitでOpenAPI仕様をすでに管理しているチーム。 | リポジトリを接続し、ブランチを同期し、ファイルを編集し、コミットしてプッシュします。 |
| ファイルバックアップ型Spec-firstプロジェクト | Gitを接続する前にファイルベースのAPI設計を行いたいチーム。 | Apidogで仕様ファイルを操作し、変更を保存し、まずワークフローを検証します。 |
ほとんどのStoplight移行において、Git接続型プロジェクトは、リポジトリが契約の信頼できる情報源として残るため、より明確な長期モデルとなります。
ファイルバックアップ型プロジェクトは、チームがオーサリング体験を評価したり、プロジェクトファイルをクリーンアップしたり、より厳格なGitワークフローを採用する前に移行を段階的に進めたい場合に役立ちます。
移行後にレビューすべきこと
プロジェクトファイルを引き継ぐことができる場合でも、移行にはレビューパスを含めるべきです。これは、大規模なドキュメントサイト、多数のスキーマファイル、またはカスタマイズされたStoplightナビゲーションを持つチームにとって特に重要です。
Spec-firstプロジェクトを作成した後、このチェックリストを使用してください。
| 項目 | 確認事項 |
|---|---|
| OpenAPIモジュール | 意図したすべての仕様ファイルがインポートされたこと、モジュール名が正しいこと、およびエンドポイントが期待どおりにグループ化されていることを確認します。 |
| 外部参照 | $refの依存関係が期待どおりに解決されたか、および変換の問題が報告されたかどうかを確認します。 |
| Lint / バリデーション | インポートされたOpenAPIファイルに対してApidogの仕様バリデーションを実行します。Apidogはルートレベルの.spectral.yaml、.spectral.yml、.spectral.json、.spectral.mjsを使用でき、Spectralベースのエディタバリデーションのために.stoplight/styleguide.jsonにフォールバックできます。検出された問題はレビューのシグナルとして扱い、Stoplightのスタイルガイドガバナンスの完全な移行とは見なさないでください。 |
.stoplight.json | サポートされているOpenAPI、Markdown、JSONスキーマのルート、OpenAPIのインクルードパターン、グローバルな除外パターン、およびtocPathを確認します。すべてのStoplight構成フィールドが適用されたと仮定するのではなく、実際のインポート出力を確認します。 |
toc.json | サポートされているグループ、区切り、タイトル、Markdownのフィルタリングと順序付け、クリック可能なグループ、OAS/モジュールリンク、選択された仕様項目リンク、TOC参照モデルのインポート、および最終的なApidogサイドバー出力を確認します。 |
| Markdownドキュメント | 書式設定、見出し、相対リンク、アンカー、およびAPIファイルまたは操作へのリンクを確認します。 |
| 画像 | ローカルで参照されている画像が正しくレンダリングされることを確認します。外部画像、データURI、壊れた参照、および未使用のアセットは別途レビューします。 |
| モデル | toc.jsonで参照されているJSONスキーマファイルのうち、どれがモデルリソースになったか、および名前、フォルダ、参照が正しいことを確認します。 |
| Stoplight ID | 繰り返し同期してもモジュールの一致が期待どおりに機能することを確認します。すべてのリソースタイプについてIDのみに依存しないでください。 |
| テストとモック | 以前にPostman、Bruno、CI、または別のツールで管理されていたシナリオを再構築または再接続します。 |
| 権限と公開 | 新しいワークスペースでチームアクセス、ドキュメントの可視性、レビュールール、およびリリース責任を再作成します。 |
このレビューは回避策ではありません。ファイルを移動することと、製品固有の全体的な体験を移動することとの間の通常の相違です。
PostmanおよびBrunoアセットについてはどうですか？
多くのStoplightチームはPostmanまたはBrunoも使用しています。これらのアセットはOpenAPIの移行とは別に計画されるべきです。
OpenAPIファイルはAPI契約を定義します。PostmanコレクションとBrunoの.bruファイルは通常、リクエストワークフロー、例、環境、またはテストを定義します。それらは価値があるかもしれませんが、StoplightスタイルのOpenAPIプロジェクトと同じ移行オブジェクトではありません。
移行前に、これらの質問に答えてください。
| 質問 | なぜそれが重要か |
|---|---|
| OpenAPIが信頼できる情報源ですか、それともコレクションが実際のAPIの動作を推進していますか？ | Spec-first移行は、権威ある契約から開始すべきです。 |
| どのリクエスト例がまだ重要ですか？ | 接続されたAPIワークスペースを中心に重要な例を再構築します。 |
| どのテストを実行し続けるべきですか？ | APIテストはドキュメントとともに移行されると仮定するのではなく、新しいワークフローに移動または再接続します。 |
| どの環境とシークレットが共有されていますか？ | 仕様移行とは別に環境管理を計画します。 |
| どのCIジョブが現在のツールに依存していますか？ | バリデーション、テスト、およびレポートを意図的に再接続します。 |
Brunoユーザーにとっての重要な洞察は、Gitネイティブのワークフローがすでに価値があるということです。Spec-firstモードは契約をファイルベースに保つことができますが、Brunoアセットはチームがそれらをどのように使用しているかに応じて、個別の移行、再構築、または置き換えが必要になる場合があります。
推奨される移行計画
すべてのAPIワークフローを一度に移動しようとするのではなく、段階的な計画を使用してください。
段階的な移行計画：まずOpenAPI契約を移動し、その後、周囲のワークフローを再接続します。
1. Stoplightスタイルのリポジトリを監査する
OpenAPIファイル、.stoplight.json、toc.json、Markdownドキュメント、モデル、画像、および関連するリクエストまたはテストアセットを特定します。
2. 信頼できる情報源を決定する
Git内のOpenAPIファイルが契約のソースであるかどうかを確認します。別のツールまたはコレクションが事実上信頼できる情報源である場合は、移行前にその問題を解決します。
3. Spec-firstプロジェクトを作成する
チームがGitを信頼できる情報源として維持する準備ができている場合は、Git接続型プロジェクトを選択します。チームがまずファイルワークフローを検証したい場合は、ファイルバックアップ型プロジェクトを選択します。
4. 引き継がれたものをレビューする
モジュール、ドキュメント、モデル、参照された画像、リンク、サポートされているtoc.jsonナビゲーション入力、サポートされている.stoplight.jsonパス設定、および仕様のバリデーション結果を確認します。手動で症状を修正するのではなく、可能な場合はプロジェクトファイルを修正します。
5. ワークフローレベルのアセットを再構築する
移行されたAPI契約を中心に、モック、テスト、リクエスト例、CIジョブ、レポート、権限、および公開責任を再接続します。
6. 新しいワークフローを通じて最初の実際の変更を実行する
小さなOpenAPIの変更を行い、レビューし、同期し、必要に応じてドキュメントを更新し、下流のモック、テスト、レポートが期待どおりに動作するかどうかを検証します。
チームがすでにOpenAPIファイル、Markdownドキュメント、およびスキーマモデルをStoplightスタイルのリポジトリで管理している場合、Apidog Spec-firstモードは、完全なワークフローを再構築する前に移行パスをテストするのに役立ちます。
この移行パスが最も適している場合
この移行パスは次の場合に適しています。
- チームがOpenAPIまたはSwaggerの仕様をファイルとして管理している場合。
- StoplightプロジェクトにMarkdownドキュメント、モデル、画像、
.stoplight.json、またはtoc.jsonが含まれている場合。 - APIレビュープロセスがすでにGitブランチまたはプルリクエストに依存している場合。
- APIドキュメント、モック、テスト、レポート、および共同作業を契約に接続したままにしたい場合。
- APIファイルと、フロントエンド、QA、製品、プラットフォーム、またはパートナーチームが使用するワークスペースとの間の乖離を減らしたい場合。
次の場合には、より多くの計画が必要になる場合があります。
- 真のAPIの信頼できる情報源がOpenAPIではなくPostmanまたはBrunoコレクションである場合。
- Stoplightプロジェクトがカスタム公開動作に強く依存している場合。
- ドキュメントに多数の外部リンク、アンカー、生成されたページ、または参照されていないアセットが含まれている場合。
- JSONスキーマモデルが手動レビューが必要なフォーマットまたは構造で保存されている場合。
- チームがStoplightのナビゲーションやドキュメントのレンダリングをピクセル単位で完全に再現したい場合。
よくある質問
Apidog Spec-firstモードはStoplightの代替となりますか？
これらのファイルの周りでより広範なAPI共同作業、テスト、モック、ドキュメント、レポート、および権限管理を追加しながら、OpenAPIプロジェクトをファイルベースに保ちたいチームにとって、Stoplightの代替として使用できます。
OpenAPI仕様をGitに保持できますか？
はい。Git接続型Spec-firstプロジェクトでは、チームはGitを信頼できる情報源として維持し、ブランチを同期し、ファイルを編集し、変更をリポジトリにコミットし直すことができます。
開始するためにGitが必要ですか？
いいえ。チームがまず仕様ファイルを操作し、後でGitを接続したい場合、ファイルバックアップ型Spec-firstプロジェクトを使用できます。
.stoplight.jsonとtoc.jsonは完全に保持されますか？
いいえ。Apidogはこれらのファイルのサポートされている部分を移行入力として使用します。.stoplight.jsonは、主に同期中のパス検出に使用され、サポートされているOpenAPI、Markdown、JSONスキーマのルート、OpenAPIのインクルードパターン、グローバルな除外、およびtocPathが含まれます。toc.jsonは、サポートされているDOCSコンテンツ、OAS/モジュールリンク、選択された仕様項目リンク、およびTOC参照モデルのインポートを整理するのに役立ちます。最終的なオンラインドキュメントのサイドバーは依然としてApidogのDOCS/OAS/MODELSモデルによって制約されるため、正確なStoplightナビゲーションや任意のクロスタイプ順序は保持されない場合があります。
Markdownドキュメントはどうなりますか？
MarkdownドキュメントはSpec-firstプロジェクトワークフローに取り込むことができます。toc.jsonが存在する場合、TOCにリストされたドキュメントは、サポートされている場合、より多くの構造を保持できます。内部リンク、アンカー、画像、およびレンダリングは引き続きレビューする必要があります。
JSONスキーマモデルはどうなりますか？
JSONスキーマモデルは、toc.jsonなどのサポートされているプロジェクト構造によって明示的に参照されている場合、サポートされている範囲で引き継ぐことができます。モデルディレクトリ下のすべてのJSONファイルが自動的にモデルリソースになるとは限りません。移行後、スキーマのフォーマット、名前、フォルダ、および参照を確認してください。
画像はどうなりますか？
Markdownによって参照されるローカル画像は、サポートされている場合、インポートできます。formats.image.rootDirを、そのディレクトリ内のすべての画像ファイルがインポートされるという保証として扱わないでください。外部画像、データURI、壊れた参照、および未使用の画像ファイルは別途確認する必要があります。
移行後にLintまたはバリデーションを実行すべきですか？
はい。移行後、インポートされたOpenAPIファイルに対して仕様のバリデーションを実行してください。ApidogはSpectralベースのエディタバリデーションをサポートしており、ルートレベルの.spectral.yaml、.spectral.yml、.spectral.json、.spectral.mjsを読み取ったり、.stoplight/styleguide.jsonにフォールバックしたりできます。結果を使用して契約とスタイルの問題を確認し、バリデーションの成功をStoplight固有のすべての動作が保持された証拠として扱わないでください。
BrunoまたはPostmanのユーザーはどうすべきですか？
まず、OpenAPIまたはコレクションが信頼できる情報源であるかを特定します。Spec-first移行はOpenAPIと関連プロジェクトファイルを中心に行われます。コレクションベースのリクエストワークフロー、環境、およびテストは、個別の移行または再構築が必要になる場合があります。
Apidogはモック、テスト、CI/CD、レポート、および共同作業もサポートしていますか？
はい。Spec-firstモードはファイルベースのAPI契約をApidogに接続し、より広範なApidogプラットフォームは、その契約を中心としたドキュメント、モック、テストシナリオ、Apidog CLIによるCI/CD実行、レポート、権限、およびチーム共同作業をサポートできます。
まとめ
Stoplightからの移行は、ファイルベースのAPI作業を諦めることを意味すべきではありません。
リポジトリは引き続き信頼できる情報源であり続けることができます。OpenAPI仕様、Markdownドキュメント、参照されている画像、TOC参照JSONスキーマモデル、およびサポートされているプロジェクト構造ファイルは、ポータブルでレビュー可能な状態を維持できます。同時に、それらのファイルを中心としたAPIワークフローは、より接続されたものになります。
Apidog Spec-firstモードは、Stoplightチームに実用的な移行パスを提供します。サポートされているプロジェクトのファイルベースの部分を引き継ぎ、Stoplight固有の構造を注意深くレビューし、接続されたAPIワークスペースを中心にワークフローレベルのアセットを再構築します。
チームがStoplightからの移行を検討している場合は、まずリポジトリ構造を監査し、どのファイルがAPI契約を定義しているかを決定することから始めてください。次に、Spec-firstモードを使用して、それらのファイルをApidogのドキュメント、モック、テスト、レポート、権限、および共同作業に接続します。
エンタープライズ移行計画については、Apidog Enterpriseを参照してください。