113

REST URI をバージョン管理する最良の方法は何ですか? 現在、URI 自体にバージョン # があります。

http://example.com/users/v4/1234/

この表現のバージョン 4 の場合。

バージョンは queryString に属していますか? すなわち。

http://example.com/users/1234?version=4

それとも、別の方法でバージョン管理を行うのが最善でしょうか?

4

11 に答える 11

192

URL をバージョン管理しないでください。理由は ...

  • あなたはパーマリンクを壊します
  • URL の変更は、インターフェースを通じて病気のように広がります。変更されていないが、変更された表現を指している表現をどうしますか? URL を変更すると、古いクライアントが機能しなくなります。URL をそのままにしておくと、新しいクライアントが機能しない可能性があります。
  • メディア タイプのバージョン管理は、はるかに柔軟なソリューションです。

あなたのリソースが application/vnd.yourcompany.user+xml のいくつかのバリアントを返すと仮定すると、新しい application/vnd.yourcompany.userV2+xml メディア タイプのサポートを作成し、コンテンツ ネゴシエーションの魔法によって v1 とv2 クライアントは平和的に共存できます。

RESTful インターフェイスでは、コントラクトに最も近いものは、クライアントとサーバーの間で交換されるメディア タイプの定義です。

クライアントがサーバーと対話するために使用する URL は、以前に取得した表現に埋め込まれたサーバーによって提供される必要があります。クライアントが知る必要がある唯一の URL は、インターフェイスのルート URL です。URL にバージョン番号を追加することは、クライアントで URL を構築する場合にのみ価値があります。RESTful インターフェースではこれを行うとは想定されていません。

既存のクライアントを壊すメディア タイプを変更する必要がある場合は、新しいクライアントを作成し、URL はそのままにしておいてください。

そして現在、メディアタイプとして application/xml と application/json を使用している場合、これは意味がないと言っている読者のために。それらをどのようにバージョン管理することになっていますか？あなたではない。これらのメディア タイプは、コード ダウンロードを使用して解析しない限り、RESTful インターフェイスではほとんど役に立ちません。

于 2009-06-10T12:57:53.403 に答える
34

v4 は v3 とは異なるリソースを識別するため、URI 自体の一部にすること (オプション 1) が最適です。2 番目のオプションのようなクエリ パラメータは、 resourceではなく、 requestに関連する追加の (クエリ) 情報を渡すために最適に使用できます。

于 2009-06-09T20:12:22.420 に答える
22

ああ、私はまた古い不機嫌そうな帽子をかぶっています。

ReST の観点からは、まったく問題ありません。ソーセージではありません。

クライアントは、追跡したい URI を受け取り、それを不透明な文字列として扱います。好きなものを入れても、クライアントはバージョン識別子などを知りません。

クライアントが知っていることは、メディア タイプを処理できるということです。Darrel のアドバイスに従うことをお勧めします。また、個人的には、安らかなアーキテクチャで使用されるフォーマットを 4 回変更する必要があるということは、重大な間違いを犯しているという巨大な警告サインをもたらすはずであり、変更に対する回復力のためにメディア タイプを設計する必要性を完全に回避していると感じています。

ただし、どちらの方法でも、クライアントは、理解できる形式のドキュメントのみを処理し、その中のリンクをたどることができます。リンク関係 (遷移) について知っている必要があります。したがって、URI の内容はまったく関係ありません。

個人的にはhttp://localhost/3f3405d5-5984-4683-bf26-aca186d21c04 に投票します

これ以上クライアント開発者やシステムに触れる人が、URI の先頭または末尾に v4 を配置する必要があるかどうかを疑問視するのを防ぐ完全に有効な識別子 (サーバーの観点から、4 を使用しないことをお勧めします)バージョン、ただし 4 つのメディア タイプ)。

于 2009-06-10T22:56:49.213 に答える
9

URLにバージョンを入れないでください。リクエストのAcceptヘッダーにバージョンを入れてください。このスレッドの私の投稿を参照してください。

APIバージョニングのベストプラクティス？

URLにバージョンを貼り付け始めると、次のようなばかげたURLになってしまいます。http： //company.com/api/v3.0/customer/123/v2.0/orders/4321/

また、他にもたくさんの問題があります。私のブログを参照してください：http: //thereisnorightway.blogspot.com/2011/02/versioning-and-types-in-resthttp-api.html

于 2011-07-19T16:13:55.020 に答える
5

REST API のバージョン管理に関する次の (あまり具体的ではない) SO の質問が役立つ場合があります。

于 2009-06-09T20:31:54.800 に答える
2

REST サービスを使用する前に認証が必要な場合は、API キー/トークンを API バージョンに簡単に関連付けて、内部でルーティングを行うことができます。新しいバージョンの API を使用するには、そのバージョンにリンクされた新しい API キーが必要になる場合があります。

残念ながら、このソリューションは認証ベースの API でのみ機能します。ただし、URI からバージョンを除外します。

于 2013-11-13T03:16:34.593 に答える
1

URIの最後にオプション値としてバージョンを含めます。これは、/ V4のようなサフィックス、または説明したようなクエリパラメータである可能性があります。/ V4をクエリパラメータにリダイレクトして、両方のバリエーションをサポートすることもできます。

于 2009-06-09T20:14:36.910 に答える