48

最初にstackoverflowで検索を行いましたが、質問に関連する回答を見つけることができませんでした. 私が見つけたのは、REST uri の設計に関する質問だけでした。

バックエンド側での私の質問。REST uri の 2 つの異なるバージョンがあるとします。

http://api.abc.com/rest/v1/products

http://api.abc.com/rest/v2/products

バージョンに基づいて、これら 2 つの API セット全体で既存のクラスを適切にルーティング、管理、および再利用するために、バックエンド側 (サーバー側コード) に従う最善のアプローチは何ですか?

たとえば、v1 と v2 のパッケージを別々に作成し、そのパッケージの ProductsResource クラスで定義するために、さまざまな @Path アノテーションを使用してリソース クラスを定義するアプローチを考えました。

    package com.abc.api.rest.v1.products;
    @Path("/rest/v1/products")
    public class ProductsResource {...}

    package com.abc.api.rest.v2.products;
    @Path("/rest/v2/products")
    public class ProductsResource {...}

& 次に、バージョンに基づいた実装ロジックを用意します。このアプローチの問題は、一連の API から特定のリソース API を 1 つだけ変更する場合に、他のクラスも v2 パッケージにコピーする必要があることです。私たちはそれを避けることができますか？

@Version と言うカスタム アノテーションを作成し、サポートするバージョンの値を指定するのはどうですか? v1 か v2 かに関係なく、両方のリクエストが同じリソース クラスに送られます。

たとえば

    package com.abc.api.rest.products;
    @Path("/rest/{version: [0-9]+}/products")
    @Version(1,2)
    public class ProductsResource {...}

アップデート：

ヘッダーでバージョンを処理するために、Jarrod による API バージョン管理の提案がありました。これも 1 つの方法ですが、URI ベースのバージョン管理に従っている場合に使用するベスト プラクティスを楽しみにしています。

4

3 に答える 3

18

それを URL に入れる際の問題は、URL が場所によってリソースを表すことになっていることです。API バージョンは場所ではなく、リソースの識別子の一部ではありません。

URL に固執/v2/すると、それ以前の既存のリンクがすべて壊れます。

API のバージョン管理を指定する正しい方法が 1 つあります。

Accept:必要なヘッダーの MIME タイプに入れます。何かのようなものAccept: application/myapp.2.0.1+json

Chain of Responsiblityパターンは、特に多数の API バージョンが独自のハンドラーを持たなければならないほど異なる場合にうまく機能し、メソッドが手に負えなくなります。

于 2013-02-14T18:28:31.693 に答える
2

ProductService のサブクラスを呼び出さないのはなぜだろうと思っていました

@Path(/v2/ProductService)
ProductServiceV2 extends ProductService {


}


@Path(/v1/ProductService)
 class ProductService{


}

v2 で変更されたものだけをオーバーライドします。変更されていないものはすべて、v1/ProductService と同じように機能します。

これは間違いなくクラス数の増加につながりますが、新しいバージョンの api で変更されたものだけをコーディングし、コードを複製せずに古いバージョンに戻す簡単な方法の 1 つです。

于 2015-04-06T20:56:08.770 に答える