Web サービス API のバージョン管理 質問する

バージョン管理は複雑なトピックなので、まずは目標をより説明的に定義する必要があります。互換性が損なわれることのないインターフェースがあると言えば素晴らしいのですが、新しい機能によってはそれが不可能な場合もあります。つまり、さまざまな状況があり、さまざまなトレードオフがあるのです。

新しい機能を新しい消費者にのみ提供することが目的で、すべての消費者が直接消費者である場合 (仲介者やフレームワークなどがない場合)、個別のエンドポイント アプローチが最適な選択です。機能の中断のリスクがある機能を追加するたびに、新しいエンドポイントを作成し、新しいバージョン番号を付けて、消費者にそれに対して検証し、構成を切り替えるように通知します。この戦略は実証済みですが、消費者に最新の状態を維持する負担がかかるという欠点があります。また、サービス間に依存関係がある場合は、追跡が面倒になる可能性があります。利点は、コードが中断しても (直接) あなたのせいではないことです。

もう 1 つの主な戦略は、拡張可能なインターフェイスです。私が知っている限り、これには 3 つの異なる種類があります。1 つ目は、サービス ドメインを非常にうまく記述しようとするタイプのインターフェイスで、既存のインターフェイスがあれば、追加できる可能性のあるすべての機能が何らかの形で可能になります。難しいように聞こえるかもしれませんが、実際難しいのです。これを完璧なインターフェイスと呼ぶこともできます。すべてが完全に記述されていますが、ドメイン全体も完全に記述されています。ただし、"完璧" というのは実際には紙の上だけです。

2 つ目の種類は、通常のインターフェイスのように見えますが、汎用的な拡張ポイントを追加するタイプです。WSDL では、これは xs:any、名前と値のペア、または同様のものを意味します。これを基本的な拡張可能なインターフェイスと呼ぶことができます。これはそれほど難しくありませんが、複雑にならないわけではありません。拡張ポイントにより、特定のツール (xs:any) でインターフェイスを操作するのが難しくなったり、入力と出力 (名前と値のペア) を検証する機能が明示的に失われたりする場合があります。また、これらの拡張ポイントを悪用してバージョン 3 または 4 を使いにくくすることも非常に簡単です。

3 つ目の種類は、インターフェースをバイト ストリームに変換するタイプです。これらは神インターフェースと呼ぶことができます。正当な理由がないわけではありませんが、これを使用している場合は、そもそも Web サービスを使用している理由を自問したほうがよいでしょう。生の TCP/IP または基本的な HTTP GET/POST について検討する必要があるかもしれません。しかし、WSDL と XSD の複雑さにうんざりしていて、ゼロから始めたいが、インフラストラクチャ上の理由で Web サービスに縛られている場合もあります。ただし、この道を歩み始めると、サービスの使用方法と使用しない方法を消費者に説明するまったく新しい方法が必要になることを認識してください。そのために XSD を使用すると、基本的に元の状態に戻ります。

最善策は、これらすべてのオプションを把握し、最初に「完璧なインターフェース」を目指してサービス設計に取り組み、その後諦めて汎用的な拡張ポイントを追加することです。完璧なインターフェースを設計しようとすると、インターフェースだけでなく、サービスを向上させるための事柄を学ばざるを得なくなりますが、時間がかかります。何らかの方法でその時間を制限しないと、永遠にかかることになります。

本当のゴッドインターフェースには少し足りないものの、ラッパーインターフェースがあります。システムにレイヤーがある場合は、インターフェースもレイヤーにする必要があります。レイヤー B を変更する場合、レイヤー C のすべてのインスタンスではなく、レイヤー B のみを変更します。