21

私はクライアントに小さな Web サービス API を提供していますが、これは時間の経過とともに進化する予定です。したがって、何らかのバージョン管理が必要ですが、そのようなことをどのように行うかについての情報が見つかりません。

ベストプラクティスはありますか?

Web サービスのコンシューマーとの互換性を損なうことなく、新しい機能を追加し続けるにはどうすればよいですか?

4

5 に答える 5

20

バージョニングは複雑なトピックであるため、まず、よりわかりやすい方法で目標を定義する必要があります。インターフェースがあれば互換性が損なわれることはありませんが、新しい機能によっては、それが不可能な場合もあります。したがって、さまざまな状況とさまざまなトレードオフがあります。

新しいコンシューマーに新しい機能を提供することだけが目的であり、すべてのコンシューマーが直接のコンシューマー (仲介者やフレームワークなどではない) である場合は、個別のエンドポイント アプローチが最適な選択です。中断の危険がある機能を追加するたびに、新しいエンドポイントを作成し、それに新しいバージョン番号を付けてから、それに対して検証して構成を切り替えるように消費者に知らせます。この戦略は十分に試行錯誤されていますが、消費者が最新情報を入手する負担がかかるという欠点があります。また、サービス間に依存関係がある場合、追跡が面倒になる可能性があります。コードが壊れた場合の利点は、(直接) あなたのせいではありません。

もう 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 のみを変更する必要があります。

于 2009-11-08T02:23:59.767 に答える
3

私は通常、バージョン文字列をWebサービスのURLに追加して、「バージョン管理されたエンドポイント」を提供します。これらのエンドポイントを実装するコードは、違いが些細で同じコードで処理できる場合は共有するか、コードを複製するか、またはその間のどこかに置くことができます。

必要に応じて、バージョンが異なるエンドポイントでもバージョン付きのXMLスキーマを使用できます。

于 2009-11-05T09:40:16.673 に答える
1

可能性の 1 つは、バージョン番号を保持する抽象型から継承する型のパラメーターを 1 つだけ持つように、すべての Web サービス操作を設計することです。このアプローチは、eBay Web サービス プラットフォームによって実装されます。次のようなもの：

<xsd:complexType name="AbstractRequestType">
  <xsd:attribute name="version" type="string" />
  ....

<xsd:complexType name="AddCustomerRequestType">
  <xsd:complexContent>
   <xsd:extension base="AbstractRequestType">
   ....

then use AddCustomerRequestType as a type of only parameter 
in addCustomer web service operation.

さらに、http で作業する場合は、バージョンを http GET パラメータとして Web サービス エンドポイント URL に追加する必要がある場合があるため、要求されたバージョンを簡単に検出できます http://server/service?version=1

于 2009-11-09T17:03:22.550 に答える
1

すべての API のパラメーターとして「API バージョン番号」を追加し、バージョン番号が使用する戦略を決定する Web サービス コードに戦略パターンを実装します。

于 2009-11-05T09:36:11.347 に答える