8

そのため、私は過去数時間、Web API のバージョニングに関する非常に素晴らしいアドバイスを探し回ってきました。私と同じくらい楽しんでいる人のために、私のお気に入りのいくつかを、順不同で:

API のバージョン管理のベスト プラクティスは?

ASP.NET MVC アプリケーションの REST API のバージョン管理

http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html

http://www.pluralsight.com/courses/web-api-design

http://www.pluralsight.com/courses/implementing-restful-aspdotnet-web-api

したがって、このすべてのアドバイスは、本質的に API の「フロント エンド」を設計する上で非常に役立ちました。API 呼び出しをバージョン管理できます...さて、難しい部分に取りかかります。

これは、月次リリースを行う複数の製品 (これは新しい製品です) を持つ企業向けの、非常にデータ駆動型のアプリケーションです。API 呼び出しの長期サポートを希望する大規模な顧客もいれば、最新リリースを希望する小規模な顧客もいます。これは、API のマイルストーン/長期サポート リリースに似たもので管理できます。偉大な。

しかし、実際には、これは非常に厄介で、非常に速くなります。私たちは、独自の Web サイトのレイヤー、ベータ版の内部/外部 API、リポジトリ レイヤー、さらには起動する SDK を分離するために懸命に取り組んできました。各リリースを別々のブランチに分けていますが、それは SAAS であり、データベースをホストしています。したがって、API 呼び出しをバージョン管理できるだけでなく、その下にあるすべてのものをバージョン管理できます。ビジネス ロジック、リポジトリ、およびデータベース。ユニット/統合テストを始めることさえやめましょう。

したがって、試みておそらく失敗する場合は、ここで 1 つの質問だけをしてください。

複数のバージョンに対応するために、階層化されたデータ駆動型の .NET アプリケーションを構築する適切なパターンはありますか?

具体的には、データベースがどのように変更されるか、およびすべてをバージョン管理するために汎用スタックを構築する方法です。私が持っているいくつかのアイデアは次のとおりです。

  • スタックの古いソース管理ブランチを更新し、これらをデプロイする
  • すべてを同じプロジェクトに保持しますが、フォルダー/名前空間をずっと使用します
  • プロジェクトをさらに分割 - API ソリューションには、ロジック/リポジトリ レイヤーの同様の概念を持つ多数の「コントローラー」プロジェクトがあります。

私たちにはかなりの数の開発者がいて、どれだけ ace のドキュメントを書いても、現実的には何かがうまくいかないときにしか読まれません。したがって、理想的には、開発者がこれを正しく理解できるように、できるだけ明白にする必要があります。

4

1 に答える 1

2

データドリブンであろうとなかろうと、あらゆる状況に適合する完璧なソリューションはありません。

これは本当に答えが難しいです。最善の策は、複数のバージョン管理戦略を使用することです。

たとえば、データベースの変更が単に新しい列を追加するだけの場合、古いバージョンの API は新しい列を無視できます。

データベースの変更により、リポジトリ レイヤーを完全に書き直す必要がある場合は、API メソッドをバージョン管理するだけでなく、新しいリポジトリと新しいコントローラーを作成することをお勧めします。次に、エンドポイントで、ルートをバージョン管理するか、消費者が代替エンドポイントを呼び出すことができます。

API のすべてのレベルで劇的な変更がある場合は、別の仮想ディレクトリを使用した IIS でのバージョン管理が解決策になる可能性があります (これには、バグ/修正のみをサポートする目的で、ソース管理に対応するブランチまたはラベルがある場合があります)。

フォルダー/名前空間のアイデアは、開発者にとって非常に混乱を招く可能性があるため、私はそれを避けます. ルーティング (すなわち [Route("/v4/Orders")]) は、それを処理するためのより良い方法かもしれません。繰り返しますが、それはコードの量と変更の性質によって異なります。

于 2015-06-05T16:41:37.683 に答える