さまざまなAPIバージョンをサポートする方法

私はRest APIを書いていますが、さまざまなバージョンのサポートをどのように処理するのが最善か疑問に思っています。これにより、URIをV2またはV3として定義する方法を意味するのではなく、必要なコードを構成する方法を意味します。

• 同時に複数のバージョンをサポートします。V1＆V2＆V3 URIは同時に有効でなければなりません。一度にサポートされる量を制限するためにV4が来るとV1を廃止します。
• 可能な限りコードの重複を避ける
• 他のバージョンに影響を与えることなく、簡単な変更をバージョンに簡単に追加できます

取れるアプローチはほとんどないと思われます。

• Gitを使用してバージョンを制御し、異なるバージョンのブランチを使用します（古いバージョンでは、基本的に新しい開発作業は行われません）。これは、最新バージョンのみがコードに含まれているため、コードの重複がないことを意味しますが、以前のバージョンは、廃止されるまで新しいバージョンのDBで動作する必要があります。

• 各バージョンが同じアプリケーションで処理され、完全に別個のコードパスを持つようにコードを複製しますが、これは多くの複製を意味します

• バージョン間で多くのコードを再利用しますが、1つのバージョンを変更すると以前のバージョンに影響を与える可能性が高くなるため、メンテナンスが難しくなります

すべてのオプションには独自の問題があるように見えるため、この問題に対処するためのベストプラクティスはありますか？

これを行う：

バージョン間で多くのコードを再利用しますが、1つのバージョンを変更すると以前のバージョンに影響を与える可能性が高くなるため、メンテナンスが難しくなります

ただし、以前のバージョンを壊さないでください。

サポートされているすべてのバージョンが正しく機能していることを確認するテストが必要です。これらのテストがない場合は、最初にテストを作成して、変更するコードをすべてカバーする必要があります。

GITリリースブランチ（または各バージョンを個別のリポジトリに分岐）を使用して古いAPIバージョンをサポートおよび維持し、場合によってはコモンズライブラリのように依存関係として共有できる再利用可能なコードを使用する組み合わせトーゴ。したがって、各APIバージョンは個別にデプロイ可能なアーティファクトになります。これにより、たとえば、API V1はcommons V1に依存し、API V2、V3、V4はcommons V2に依存できるように柔軟性が得られます。コードベースは新しいバージョンごとに増えないため、開発の観点からはこれが最も簡単でクリーンなものになります。代わりに、すべてのバージョンが独自のプロジェクト/コードベースに分離され、それ自体にのみ関心があります。

別のアーティファクトをデプロイするもう1つの理由は、セキュリティメカニズムのような横断的な関心事、またはAPIの新しいバージョンで変更される可能性のある依存関係注入フレームワークのようなフレームワーク/ライブラリがあり、古いAPIをサポートするのが非常に困難になる可能性があることですすべてが同じコードベース（およびJavaの場合は実行時のクラスローダー）に存在します。

バージョンごとのブランチであれ、モノリシックな複製コードベースであれ、すべてのアプローチには、変更が必要な共通の統合ポイント（DBや分散キャッシュスキーマなど）の問題が常にあります。古いバージョンのAPIでは、これらの変更に対応するために何らかのメンテナンスが必要になる場合があります。または、互換性を確保するために他のツール（データベースビューなど）を導入する必要があります。これは、変更の性質によっては避けられない困難になる場合があります。

APIバージョンと結果の違いはわかりませんが、バージョンを切り替えてギャップを埋めたり、データを変換したりできる互換性レイヤーを中央に置くことができます。

とはいえ、通常は1対1で機能することはありません。そのため、スイッチまたはステートマシンタイプの設計がこの問題の解決に役立ちました。