4
バージョン管理されたAPIの基盤となるコードベースをどのように管理しますか？
私はReST APIのバージョン管理戦略について調べてきましたが、それらのどれも対処していないように見えるのは、基盤となるコードベースの管理方法です。 我々は、APIへの変更を壊すの束を作っているとしましょう-例えば、それは別の返すように私たちのお客様のリソースを変更forenameし、surname代わりに、単一のフィールドnameのフィールド。（この例では、関連する概念を理解するのは簡単なので、URLバージョン管理ソリューションを使用しますが、質問はコンテンツネゴシエーションまたはカスタムHTTPヘッダーにも同様に適用できます） これで、にエンドポイントがhttp://api.mycompany.com/v1/customers/{id}あり、別の互換性のないエンドポイントがにありますhttp://api.mycompany.com/v2/customers/{id}。私たちはまだv1 APIのバグ修正とセキュリティ更新をリリースしていますが、新機能の開発はすべてv2に焦点を合わせています。APIサーバーへの変更をどのように記述、テスト、およびデプロイしますか？私は少なくとも2つの解決策を見ることができます： v1コードベースのソース管理ブランチ/タグを使用します。v1とv2は個別に開発およびデプロイされ、両方のバージョンに同じバグ修正を適用するために必要に応じてリビジョンコントロールマージが使用されます。これは、以前のバージョンをサポートしながらメジャーな新しいバージョンを開発するときにネイティブアプリのコードベースを管理する方法と同様です。 コードベース自体にAPIバージョンを認識させると、v1の顧客表現とv2の顧客表現の両方を含む単一のコードベースが作成されます。デプロイメントの問題ではなく、ソリューションアーキテクチャの一部としてバージョン管理を扱います。おそらく名前空間とルーティングのいくつかの組み合わせを使用して、要求が正しいバージョンで処理されるようにします。 ブランチモデルの明らかな利点は、古いAPIバージョンを削除するのが簡単であることです。適切なブランチ/タグのデプロイを停止するだけですが、複数のバージョンを実行している場合、ブランチ構造とデプロイパイプラインが非常に複雑になる可能性があります。「統一されたコードベース」モデルはこの問題を回避しますが、（不要だと思いますか？）不要になったリソースとエンドポイントが不要になったときにコードベースから削除することをはるかに難しくします。単純な正解はありそうもないので、これはおそらく主観的ですが、複数のバージョンにわたって複雑なAPIを維持している組織がこの問題をどのように解決しているかを知りたいと思います。