4

現在、ASP.NET Web API を使用して実装された RESTful API を設計しています。
非常に重要なポイントの 1 つは、下位互換性です。
クリーンで最新の設計を保証するために、実際の API コードには下位互換性を考慮しないようにしたいと考えています。
バージョン トランスレータの層を設けることで、これを解決することを考えました。
これらの各トランスレータは、ある特定のバージョン (vPrevious) の要求と応答を別の特定のバージョン (vCurrent) の要求と応答に変換する方法を知っています。
これらのトランスレータは簡単に積み重ねることができ、任意の数の古いバージョンとの下位互換性を確保できます。
これらの各トランスレータは、新しいプロパティのデフォルト値の設定やさまざまな操作の配列の実行など、あらゆる種類の処理を担当します。

DelegatingHandlerクライアントが使用したい API のバージョン番号を調べ、それに基づいてどのトランスレーターを使用するかを判断する を実装することを考えました。
ただし、実際にこれを実装する方法がわかりません。私が見ているように、実際には各トランスレータは、ルーティング テーブルとコントローラと共に、独自の本格的な ASP.NET Web API である必要があります。それは実際には受け入れられますが、トランスレータ コントローラはデータをチェーン内の次のコントローラにどのようにルーティングするのでしょうか?

4

1 に答える 1

3

最もクリーンな方法は、サポートする必要のある各バージョンを実行し続けることだと思います。つまり、各バージョンにはVCSに独自のブランチがあり、その特定のバージョンを使用しているクライアントにサービスを提供することに重点が置かれています。コードはクリーンで、1つのバージョンに焦点を合わせています。一般的なコンポーネント/データベースなどに対して作業する必要がある場合は、REST APIレイヤーではなく、アーキテクチャのさらに下にそのレイヤーを実装する必要があると思います。このバージョン管理レイヤーは、RESTAPIの背後にある最初のレイヤーである必要があります。

それが実際に機能しない場合は、おそらく最新のAPIが実際のバックエンドに対して機能する唯一のAPIになるように設計します。他のバージョンは、通常のHTTPリクエストを介して他のバージョンを呼び出すだけです...古いバージョンは新しいAPIのRESTクライアントです。これは超高速ではありませんが、デザインは非常にクリーンで、バージョン管理コードがどこに行くのかを理解するのは簡単です。古いAPIバージョンに対して機能するクライアントが多数ある場合、ソリューションが遅すぎる可能性があり、より効果的な方法を見つける必要がありますが、その後、ほぼ最初のソリューションに戻ります。

于 2012-11-04T23:13:20.233 に答える