0

私たちは、REST Web サービスを、特にビジネスを「将来的に保証する」方法と見なしています。REST Web サービスのバージョン管理のさまざまな方法のトレードオフについて考えています。REST Web サービスのバージョン管理に関して、他の人が学んだことを知りたいです。

Web サービスのバージョン管理について SO やその他の場所で多くの良い議論がありますが、それらのほとんどは、バージョン番号を URL または要求ヘッダーのどちらに入れるかに焦点を当てています。

Web サービスのバージョン管理には、複数の側面があります。Web サービス呼び出し自体 (URL またはヘッダー) でバージョンを指定しています。ソース コードで複数のバージョンのビジネス ロジックを管理しています。バージョン管理された Web サービスの構築があります。バージョン管理の問題があります。そして、廃止されたバージョンをどのように非推奨にしてドロップするかという問題があります。

モバイルクライアントを作成しているパートナーは、URL にバージョンを入れたいと考えているので、それが私のアプローチです (今のところ)。さらに、これらの Web サービスの新しいバージョンは、古いバージョンと互換性がない場合があります。たとえば、異なるバージョンでは異なるセキュリティ実装が存在する場合があります。

バージョン管理された URL に関しては、通常 2 つのアプローチが提案されます。URL にバージョン番号を入れるか、パラメーターにするかです。

context-root/service/rest/v0.1/restMethod/param1

context-root/service/rest/restMethod/param1?version=v0.1

2 番目の方法では、要求を適切な実装にルーティングするためのコントローラー ロジックが必要ですが、それは難しくありません。両者の選択は難しくありません。

3 番目のオプションは、バージョン番号を context-root 自体に入れることです。これは、バージョン番号を .war ファイル名プレフィックスまたはデプロイメント記述子に入れることを意味します。

restarchive-v0.1/service/rest/restMethod/param1

これは、現在サポートされているすべてのバージョンに対して複数のアーカイブを展開することを意味します。

ファイル名にバージョン番号を付けるのが好きです。展開されているものを簡単に確認できます。このアプローチの欠点は、バージョン管理されたアーカイブごとに、おそらく Maven プロファイルを使用して、個別のビルドが必要になることです。

最初のアプローチのコードは次のようになります。各 Web メソッドは、そのメソッドでサポートされているすべてのバージョンに対して独自のコントローラー ロジックを実行します。各バージョンのビジネス ロジックは適切な方法で処理できます (つまり、パッケージにバージョン番号を入れる)。

    @ApplicationPath("/service/rest")
    @Path("/{version}/")
    public class RestService extends Application {

    @GET
    @Path("/user/{id}")
    @Produces(MediaType.APPLICATION_JSON)
    public User getUser(@PathParam("version") String version, @PathParam("id") int id) {

        User user;
        if (version.equals("v0.1")) {
            //  call v0.1 code to get the User
         }
         else if (version.equals("v0.2")) {
            //  call v0.2 code to get the User
         }
         else {

             throw new WebApplicationException(Response.Status.NOT_FOUND);
         }

         return user;
    }

}

これの最初の実装では、パッケージ内のバージョン番号を持つさまざまなパッケージで javax.ws.rs.core.Application の複数のサブクラスを使用しました。これは機能するはずですが、JBoss RESTeasy 実装では、1 つの .war で Application の複数のサブクラスを使用できません。これは明らかに JAX-RS 1.1 仕様に違反していますが、JBoss や RESTeasy を使用する場合はこれを受け入れる必要があります。

上記と同様の実装で最初のアプローチを使用する傾向があります。私は将来的に問題を最小限に抑えようとしているので、バージョン Web サービスのさまざまな側面の経験を通じて他の人が学んだことを聞きたいです。

これは健全なアプローチですか、それともここで言及していない問題につながるのでしょうか?

4

1 に答える 1

0

このトピックは JavaOne で取り上げられたもので、正解はありません。

これに触れたプレゼンテーションを行った人は、彼の好みはバージョンをヘッダーに保持し、それを URL またはクエリパラメーターとして配置することを避けることであると述べました。

個人的には、ファイル自体をバージョン管理しています。とにかく、個別にバージョン管理されたビルドをデプロイする必要があるため、それほど面倒ではありません。マニフェストからバージョン # を取得し、ファイルに ?{version} を追加するだけです。

于 2012-10-05T19:32:22.560 に答える