2009-05-31 14 views
21

さまざまなバージョンのWebサービスの処理方法に関するベストプラクティスについてお聞きしたいと思います。Webサービスを更新またはバージョン管理するための戦略?

Webサービスとして公開されているWebメソッドがある場合は、機能/機能を追加してメソッド呼び出しのシグネチャを変更したいのですが、これをどのように扱いますか現在サービスを呼び出しているお客様のすべてを壊すことはありませんか?

サービスを別のURLに展開していますか?

あなたは、パラメータリストと一緒にメソッド呼び出しの一部としてバージョンに渡してください - (..うわMyMethodは、MyMethodv2など)

あなたは、メソッド名自体にバージョンを入れますか?

GoogleやAmazonがこのシナリオを広範なWebサービスライブラリで処理する方法を知っている人はいますか?

編集:これまでのところ私はこの良い情報を見つけましたarticle from Oracle。また、いくつかのJava仕様ではthis blog entryが役に立ちました。私はまだ他のアプローチのいくつかを見て興味があります。

+0

参考のためのリンクは次のとおりです。http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ –

+0

オラクルの記事は移動しました。私はこれだと思う:http://www.oracle.com/technetwork/articles/web-services-versioning-094384.html – Paddy

答えて

14

Webサービスをバージョン管理する典型的な方法は、クライアントに希望のバージョンを指定させることです。 "> 2.0"、 "< 1.5"、または "= 1.1"のような単純な制約を許可することができます。もちろん、サポートしているバージョンの数を最小限に抑えて、自分の正気にしたいと思っています。クライアントがバージョンを指定していない場合は、最新バージョンを想定します。

バージョンを提供するためのテクニックはさまざまです。 URLを使用することを唱える人もあれば、ヘッダーを推奨する人もいれば、api呼び出しのパラメータとして含める人もいます。しかし、ほとんど誰もメソッドの名前を変更しません。 OSGiリンクをバージョン管理する "パッケージ"または "名前空間"と同等のことが言えます。アップグレードが非常に難しくなり、実際のサービスの変更よりもアップグレードが妨げられます。

また、ウェブサービスにアクセスする方法によって異なります。 RESTを使用している場合は、URLをきれいに保ち、ヘッダーを使用することが最も理にかなっています(必要に応じて、クエリパラメータとしてハックするのは簡単です)。 SOAP/XMLRPC/whatever-RPCを使用している場合は、URLに入れるのが通常です。

編集2011分の5 FWIW、私は、Apigee's blog recommends putting the version in the URLを反対するけれども。

クライアントがバージョンを指定する方法は、通常かなり簡単です。さらに複雑なことは、すべてのバージョンを同時に実行する方法です。ほとんどの言語では、同じランタイム環境(VM、プロセス、その他のもの)に同じライブラリ/モジュール/クラス/関数の複数のバージョンをロードする方法はありません。あなたが提供したOSGiリンクは、これを可能にするJavaのソリューションです。

実際には、ほとんどの状況でOSGiが過剰使用されます。通常、廃止予定のリクエストを別のサーバーまたはプロセスにプロキシする方が簡単です。

サービスを「バージョンアップする」最も良い方法は、拡張性と柔軟性を構築して前方互換性と後方互換性を維持することです。これは、すべてのバージョンが互いに互換性がなければならないわけではありませんが、連続したバージョンはお互いに互換性がある必要があります。

+1

+1 - すばらしい答え。洞察に感謝します。 SOAPを使用してOracle/Javaサービスに接続しています。 –

+0

RESTとRPCの区別は興味深いものです。非常に洞察力のある。URLまたはネームスペースの –

+1

? –

5

私は、doAPIFunction、doAPIFunctionV2、doAPIFunctionV3などを作成するソリューションは、私が働いているところで頭痛だけではないことを伝えています。それに加えて、明確に記述的な機能名の欠如はあらゆる種類の狂気を意味する。

明確なAPI関数名が必要です.APIが変更されている場合は、できるだけ後方互換性のある方法で試してみることをお勧めします。私はエントリポイントのバージョニングを提案して、各エントリーポイントが安定したAPIをサポートしていて、example.org/api-1.0/のdoFunctionは、セマンティクスを変更する正当な理由があればexample.org/api-2.0と異なる場合があります。

1

私はあなたの質問を正しく理解しているか分かりません。しかし、私の2セント。 メソッドのシグネチャが別の新しいパラメータのように変化した場合、なぜオプションにすることができないのですか?しかし、既存のパラメータのデータ型が変更された場合は適用されません。

これが間違っている場合は、これを投票してください。 :)

+1

この質問はあなたの答えに答えるべきである。オプションのパラメータを使うことができるかどうかは、あなたの言語それをサポートします。 http://bytes.com/groups/net-c/730388-web-service-optional-parameters –

+0

@James、それは良いリンクです。そのフォーラムは、なぜMattが過負荷を試みることができないと指摘したのでしょうか? – blntechie

+1

Webサービスは、オプションのパラメータやオーバーロードをサポートしていないため、使用している言語は問題ではありません。 –

1

これまでは、同じWebサービスメソッド名と異なるパラメータを数年前に持つことができましたが、これは以前より簡単でした。 :)

ウェブサービスを作成したら、クライアントと契約してこれをサポートします。

古い方法では、それらが使用されているかどうかを確認するためにロギングし、誰が更新することができるかを確認することをお勧めします。

これ以外の方法で新しいメソッドを作成するだけで、バージョンによって異なるいくつかの類似した関数名を持つことができます。

バージョン番号を渡す際の問題は、クライアントが常に有効な番号を渡すようにすることです。スタブが生成されればそれを実行しますが、そうでなければ非常に脆弱です。

名前にバージョン番号を付けると、古いものが明白になり、古いバージョンのWebサービスメソッドをより簡単にログに記録できるようになります。

0

これを軽減する1つの方法は、契約してインターフェイスを設定することです。 ファンクションシグネチャを変更することはできませんが、オーバーロードすることはできます。 .NET APIについて考えてみましょう。いくつかのメソッドを非難しますが、それらのコード化されたプログラムが壊れるかもしれないので、それらは動作し続けます。新たなバージョンのサービスは別のURI(v2.webservice.com)で公開され、新しいロードマップを提供し、v1は引き続きサポートする必要があります。

+0

答えてくれてありがとうございましたが、私の質問は、プロダクションでのWebサービスのバージョニングをどのように扱うかという方向に向かっていました。たとえば、MyWebMethod(int i、int x)とMyWebMethod(int i、int x、int y)を実行し、これを配置でどのように処理するのですか?すべてのコーディングプロジェクトでVCS用にSVNを使用しています。 –