私は、さまざまなクライアント アプリの中心となる Java ベースの RESTful Web アプリケーションを開発しています。これらのクライアント アプリは、メイン システムで同じアセットを操作できます (たとえば、クライアント アプリ A がメイン システムでアセットを作成し、クライアント アプリ B がシステムからアセットを取得します)。/v1/ API バージョンをロールアウトし、/v2/で新機能を開発しました。要件は、すべてのクライアント アプリが v2 に移植されるまで、v1 の後方互換性を一定期間サポートしながら、v2 をリリースすることです。この要件の背後にある考え方は、異なる API バージョンに対して作成された可能性のあるクライアント アプリが、同じアセットで引き続き連携できる必要があるということです。
現在、システムの 1 つのインスタンス内で両方の API バージョンをカバーしています。HTTP API のいくつかの小さな変更については、通常は新しいコントローラー (ブリッジ パターンのようなもの) を提供するだけで十分ですが、少し大きな変更については、新しいコントローラーとサービス レイヤーを作成するのが最善のようです (両方のバージョンがいくつかのレベルで、共通の機能セットを再利用します)。
ただし、今後はさらに広範な変更が予定されています。さらに、メイン システムは単なる CRUD ではなく、いくつかの非同期ジョブの処理などを含む少数の外部サービスと統合された、複雑なマルチコンポーネント ネットワークです。確かに、下位互換性を維持するための便利な場所です。行動的に。
コードを混乱させずに、API とその背後にある動作の下位互換性を維持するためのベスト プラクティスはありますか?
私たちはコードの品質に気を配っており、コピー、貼り付け、調整のクラスでコードを汚染したり、重複/並列機能の実装を維持したりすることを嫌います。はい、v1 と v2 の Java パッケージは既に分割されています。
また、古いバージョンのコードが私たちの手を縛って、新しいバージョンのアーキテクチャを再設計することを妨げている状況は避けたいと思います。これは、この後方互換性を維持する単純さのためです。