web-dev-qa-db-ja.com

クライアントとサーバーのバージョン間の相互運用性

同様の質問： マルチサイドプロジェクトでバージョン管理をどのように処理しますか？

上記の質問はほぼ4年前に行われたので、新しいアイデアが出てきたのではないかと思っていました。

-

複数のインスタンスを持つプラットフォームを開発している状況があります。例えば：

一般に、すべてのインスタンスは密接に同期されたバージョンのライフサイクルを持つ必要がありますが、テストを目的とした早期アクセスバージョンのインスタンスが必要になる場合があります。

上記に加えて、インスタンスに接続するAndroid/iOSアプリを用意します（ユーザーはどちらを選択する必要があります）。すべてのインスタンスが異なるデータベース上で動作することに注意することが重要です。これらの間にはレプリケーションが存在しないはずです。

問題：

サーバー側に変更を加えたら、サーバーとクライアントの両方のバージョンの新しいバージョンをリリースします。

サーバーの場合、どのバージョンがどのインスタンスにインストールされるかを制御するので、それは簡単なはずです。

クライアントの場合、新しいクライアントアプリのバージョンをリリースするとすぐに、ユーザーはそれぞれのストアからそれをプルしてインストールできますが、実際に何が起こるか古いサーバーバージョンを実行しているインスタンスを使用しますか？または、古いバージョンのAndroid/iOSが原因でクライアントが更新できない場合は？

それをどのように処理するかについてのアイデアはありますか？

私が持っていたのは、エンドポイントを提供することでした/version.jsonクライアントアプリケーションがサーバーのバージョンを取得し、操作方法を選択できるようにします。しかし、これは私見ですが、大規模なコードの肥大化/複製にすぐにつながる可能性があります。どう思いますか？

architecturerestversioningserver-side
7
Jovan Perovic

バージョンの適応を処理するカスタムプロキシおよびスタブ

したがって、これをうまく機能させるには、APIをバージョン管理する必要があります。フィールドでアクションが発生する可能性があるAPIのバージョンごとに、新しいバージョンが必要です。

次に、ライブラリー（このWS APIにアクセスするすべての言語用）を作成します。これは、そのAPIのネイティブ言語バインディングです。

note-一部の言語では、プロキシとスタブを自動的に作成するツールが提供されています。これらは内部で使用できますが、この目的で直接公開しないでください（サービスAPIのクライアント/スタブライブラリ）。

公開されたライブラリAPIは常にプロトコルの最新バージョンと一致する必要があります（可能な限り、異なるバージョンに対応するために少し一般化する必要があることはほとんどありません）。

このプロキシ/スタブAPIは、通信の開始時に、通信するピアのバージョンを確立し、必要に応じて通信をダウングレードできます。

note-astypical、ほとんどのメソッドでは、このプロキシ/スタブレイヤーかなり単純な場合もありますが、すべてのプロトコル変換が行われるレイヤーを提供します。

次に、サーバー/クライアントコードのすべての残りの部分（これもプログラミング言語で）は、ライブラリAPIに書き込まれるだけです。これは、最新の（サーバー/クライアントコードが作成された時点の）バージョンのプロトコルと一致します。

C++、Python、C＃.net、JavaScriptを使用する複数のプロジェクトでこのアプローチを使用しました。

4
Lewis Pringle

プロトコルの異なるバージョン間で受け渡されるmessagesを確実に理解できるようにすることに焦点を当てます。

大まかに言うと、これは

  • メッセージに新しい必須フィールドを追加することはありません
  • オプションのフィールドを追加できますが、プロトコルでデフォルト値を指定する必要があります
  • フィールドが新しい意味で再利用されることはありません。
  • 消費者は、認識されないオプションのフィールドを無視する必要があります

だから私が知らないオプションのフィールドがあるメッセージを私に送ったとしても、私はそれを無視します。メッセージに必要なオプションフィールドがない場合は、メッセージプロトコルを使用して、使用するデフォルト値を決定できます。

これをかなりうまくカバーしている1つのリファレンスは、Greg Youngの イベントソースシステムでのバージョン管理 です。

XMLが優勢だったとき、セマンティクスを無視する必要があることが一般的なトピックでした。デビッドオーチャードを参照してください。

Eric Wilde： Patterns for Robust Extensibility もご覧ください。

4
VoiceOfUnreason

サーバーAPIのバージョン管理 。クライアントは、APIの現在のバージョンを知る必要はありません。クライアントは、インスタンスがサポートするAPIのバージョンを知る必要があります。

バージョン付きリソースを要求するための2つの一般的なオプションがあります。リクエスト元のバージョンをURIに含めるか、HTTPヘッダーに含めることができます。

URIのバージョン管理を含む例：

GET http://instance{x}.myplatform.com/v1/{resource}

ヘッダーにバージョン管理を含む例：

GET http://instance{x}.myplatform.com/{resource}
X-API-Version: v1

GET http://instance{x}.myplatform.com/{resource}
Accept: application/json+v2

もちろん、両方の方法をサポートすることもできます。メジャーバージョン番号のみが含まれていることに注意してください。 セマンティックバージョニング を使用している場合、クライアントは実際に使用しているメジャーバージョン番号のみを認識する必要があります（これは、下位互換性が失われた場合にのみ変更されるためです）。必要に応じてバージョン番号全体を指定することもできますが、実行する必要のあるコードを判別するためにサーバー側で処理する必要があるロジックが増える可能性があります。クライアントはそれが開発されたAPIのバージョンを知っているので、要求を行うときにその情報を読み取り可能にできるはずです。

これは、古いバージョンのAPIをぶらぶらさせる必要があることを意味しますが、古いバージョンのクライアントが実際に公開されており、更新のタイミングを制御できないため、理にかなっています。バージョンごとにAPIの使用状況を監視し、プラグがプルされ、しきい値を下回ったときにプラグを完全に削除することを決定できます。

きみの /version.jsonアプローチは、APIインスタンスがサポートするメジャーバージョンが異なる状態になる可能性がある場合に役立ちます。その場合、ユーザーが接続するインスタンスを選択する前に、ユーザーに問い合わせて、クライアントが必要とするAPIのバージョンをサポートしているかどうかを判断する必要があります。そうでない場合、クライアントはそれらに接続することを望まないでしょう。

4
Jeff Lambert