117

私は ReST API のバージョン管理戦略について調べてきましたが、それらのどれも解決していないように見えるのは、基礎となるコードベースをどのように管理するかということです。

たとえば、単一のフィールドではなく個別forenameのフィールドを返すように Customer リソースを変更するとします。(この例では、関連する概念を理解しやすいため、URL バージョン管理ソリューションを使用しますが、質問はコンテンツ ネゴシエーションまたはカスタム HTTP ヘッダーにも同様に適用できます)surnamename

にエンドポイントが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 を維持している組織がこの問題をどのように解決しているかを理解したいと思っています。

4

4 に答える 4

13

私にとっては、2番目のアプローチの方が優れています。SOAP Web サービスに使用しており、REST にも使用する予定です。

あなたが書いているように、コードベースはバージョンを認識している必要がありますが、互換性レイヤーを別のレイヤーとして使用できます。あなたの例では、コードベースは姓名でリソース表現 (JSON または XML) を生成できますが、互換性レイヤーは代わりに名前のみを持つように変更します。

コードベースは、v3 などの最新バージョンのみを実装する必要があります。互換性レイヤーは、最新バージョン v3 とサポートされているバージョン (v1 や v2 など) の間で要求と応答を変換する必要があります。互換性レイヤーには、チェーンとして接続できる、サポートされているバージョンごとに個別のアダプターを含めることができます。

例えば：

クライアント v1 リクエスト: v1 は v2 に適応 ---> v2 は v3 に適応 ----> コードベース

クライアント v2 要求: v1 は v2 に適応 (スキップ) ---> v2 は v3 に適応 ----> コードベース

応答の場合、アダプターは単純に反対方向に機能します。Java EE を使用している場合は、たとえば、サーブレット フィルター チェーンをアダプター チェーンとして使用できます。

1 つのバージョンを削除するのは簡単です。対応するアダプターとテスト コードを削除します。

于 2016-04-07T21:06:42.967 に答える
6

分岐は私にとってはるかに優れているようで、私の場合はこのアプローチを使用しました。

はい、すでに述べたように、バグ修正のバックポートにはいくらかの労力が必要ですが、同時に1つのソースベースで複数のバージョンをサポートするには（ルーティングやその他すべてのものを使用して）、少なくとも同じ労力が必要であり、システムをより多くする必要があります内部にロジックのさまざまな分岐がある複雑で巨大です（バージョン管理のある時点で、case()コードが複製されているか、さらに悪いバージョンモジュールを指していることは間違いありませんif(version == 2) then...）。また、リグレッションのために、テストの分岐を維持する必要があることも忘れないでください。

バージョン管理ポリシーについて: 現在のバージョンから最大 -2 バージョンを保持し、古いバージョンのサポートを廃止します。これにより、ユーザーが移動する動機が得られます。

于 2015-06-02T17:50:15.907 に答える
0

通常、API のメジャー バージョンの導入により、複数のバージョンを維持しなければならない状況に陥ることは、あまり頻繁に発生しない (または発生すべきではない) イベントです。ただし、完全に回避することはできません。メジャー バージョンが導入されると、比較的長期間にわたって最新バージョンが維持されるというのは、全体として安全な仮定だと思います。これに基づいて、重複を犠牲にしてコードを単純化することを好みます。これにより、最新バージョンに変更を加えたときに以前のバージョンを壊さないという確信が持てるようになります。

于 2020-03-20T15:57:28.727 に答える