回答:
URI自体の一部（オプション1）にするのが最善だと思います。v4はv3とは異なるリソースを識別するためです。2番目のオプションのようなクエリパラメータは、リソースではなく、リクエストに関連する追加の（クエリ）情報を渡すのに最適です。
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インターフェースにはほとんど役に立ちません。その時点で、バージョン管理は重要なポイントです。
ああ、私は再び古い不機嫌そうな帽子をかぶっています。
ReSTの観点からは、それはまったく問題ではありません。ソーセージではありません。
クライアントは、追跡したいURIを受け取り、不透明な文字列として扱います。その中に何を入れても、クライアントはバージョン識別子などを認識しません。
クライアントが知っているのは、メディアタイプを処理できることです。私は、Darrelのアドバイスに従うことをお勧めします。また、私は個人的に、安静なアーキテクチャで使用されているフォーマットを4回変更する必要があると、何か深刻な問題が発生していることを示す巨大で大きな警告の兆候をもたらし、変更の回復力のためにメディアタイプを設計する必要性を完全に回避できると感じています。
ただし、どちらの方法でも、クライアントは、理解できる形式のドキュメントのみを処理し、そのリンクをたどることができます。リンク関係（遷移）について知っている必要があります。したがって、URIの内容はまったく無関係です。
私は個人的にhttp：// localhost / 3f3405d5-5984-4683-bf26-aca186d21c04に投票します
URIの最初または最後にv4を配置する必要があるかどうかを質問するために、以降のクライアント開発者またはシステムに触れる人を防ぐ完全に有効な識別子（およびサーバーの観点から、4バージョン、ただし4つのメディアタイプ）。
バージョンをURLに含めないでください。バージョンをリクエストのAcceptヘッダーに含めてください。このスレッドの私の投稿を参照してください。
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
REST APIのバージョン管理に関する次の（それほど具体的ではない）SOの質問が役立つ場合があります。
APIのバージョン管理には4つの異なる方法があります。
URIパスにバージョンを追加：
http://example.com/api/v1/foo
http://example.com/api/v2/foo
重大な変更がある場合は、次のようにバージョンをインクリメントする必要があります：v1、v2、v3 ...
次のようなコードでコントローラを実装できます。
@RestController
public class FooVersioningController {
@GetMapping("v1/foo")
public FooV1 fooV1() {
return new FooV1("firstname lastname");
}
@GetMapping("v2/foo")
public FooV2 fooV2() {
return new FooV2(new Name("firstname", "lastname"));
}
リクエストパラメータのバージョン管理：
http://example.com/api/v2/foo/param?version=1
http://example.com/api/v2/foo/param?version=2
APIの使用方法に応じて、バージョンパラメータはオプションまたは必須になります。
実装は次のようになります。
@GetMapping(value = "/foo/param", params = "version=1")
public FooV1 paramV1() {
return new FooV1("firstname lastname");
}
@GetMapping(value = "/foo/param", params = "version=2")
public FooV2 paramV2() {
return new FooV2(new Name("firstname", "lastname"));
}
カスタムヘッダーを渡す：
http://localhost:8080/foo/produces
ヘッダー付き：
headers[Accept=application/vnd.company.app-v1+json]
または：
headers[Accept=application/vnd.company.app-v2+json]
このスキームの最大の利点は、主にセマンティクスです。バージョン管理に関係することでURIを乱雑にする必要はありません。
可能な実装：
@GetMapping(value = "/foo/produces", produces = "application/vnd.company.app-v1+json")
public FooV1 producesV1() {
return new FooV1("firstname lastname");
}
@GetMapping(value = "/foo/produces", produces = "application/vnd.company.app-v2+json")
public FooV2 producesV2() {
return new FooV2(new Name("firstname", "lastname"));
}
ホスト名の変更またはAPIゲートウェイの使用：
基本的に、APIをあるホスト名から別のホスト名に移動します。同じリソースに対して新しいAPIを構築するためにこれを呼び出すことさえできます。
また、APIゲートウェイを使用してこれを行うこともできます。
バージョン管理されたAPIを作成したかったのですが、この記事は非常に役に立ちました。
http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http
「APIをバージョン管理したい」という小さなセクションがあります。シンプルでわかりやすいと思いました。重要なのは、ヘッダーのAcceptフィールドを使用してバージョン情報を渡すことです。
バージョン管理にURIを使用する場合は、バージョン番号をAPIルートのURIに含める必要があります。これにより、すべてのリソース識別子にバージョン番号を含めることができます。
技術的には、REST APIはURLの変更（統一されたインターフェース制約の結果）によって壊れることはありません。関連するセマンティクス（たとえば、API固有のRDF語彙）が下位互換性のない方法（まれ）で変更された場合にのみ機能します。現在、多くのpplは、ナビゲーション（HATEOAS制約）とボキャブのリンクを使用してREST応答（自己記述型メッセージ制約）に注釈を付けていないため、クライアントが壊れています。
関連するメタデータと表現の構造を短い文字列に入れても機能しないため、カスタムMIMEタイプとMIMEタイプのバージョン管理は役に立ちません。Ofc。メタデータと構造は頻繁に変更されるため、バージョン番号も...
したがって、質問に答えて、要求と応答にvocabs（Hydra、リンクされたデータ）で注釈を付け、バージョニングを忘れるか、下位互換性のない語彙の変更によってのみ使用する（たとえば、語彙を別の語彙に置き換える場合）。