1 に答える
あなたがここに持ってきているものは、私にはバージョン管理としては見えませんが、それはより多くのコンテンツネゴシエーションです。Acceptヘッダーは、リソースの形式に関するクライアントの希望を表します。サーバーはウィッシュを許可するか、406を返す必要があります。したがって、コントラクトの概念がさらに必要な場合（Web API unline RPCでは定義されていませんが）、リソースの使用はより確実です。
バージョニングのベストプラクティスについてはまだ十分に説明されていませんが、ほとんどのREST愛好家は、URLでバージョンを使用することが道のりであると信じています（例http://server/api/1.0.3/...）。コンテントネゴシエーションサーバーを使用するアプローチでは下位互換性を維持する必要があり、サーバーのコードがますます複雑になることしか想像できないため、これは私にとっても理にかなっています。URLアプローチを使用すると、すっきりとした休憩をとることができます。古いクライアントは以前のクライアントを喜んで使用でき、新しいクライアントは新しいAPIのメリットを享受できます。
アップデート
OK、質問は「RESTfulAPでのコンテンツネゴシエーションの実装」に変わりました。
タイプ1：コントローラー-気付かない
基本的に、コンテンツネゴシエーションにリソースのフォーマットのみが含まれる場合は、適切なメディアタイプフォーマッタを実装または使用するだけで十分です。たとえば、コンテンツネゴシエーションにJSONまたはXMLを返すことが含まれる場合。このような場合、コントローラーはコンテンツのネゴシエーションを認識しません。
タイプ2：コントローラー対応
コントローラは、要求のネゴシエーションを認識する必要があります。この場合、リクエストのパラメータをリクエストから抽出し、パラメータとして渡す必要があります。たとえば、コントローラーでのこのアクションを想像してみましょう。
public Player Get(string schemaVersion)
{
...
}
この場合、私は古典的なMVCスタイルの値プロバイダーを使用します（ValueProvidersに関するBrad Wilsonの投稿を参照してください-これはMVCにありますが、Web APIの値プロバイダーは似ています）：
public Player Get([ValueProvider(typeof(RequestHeadersSchemaValueProviderFactory))]string schemaVersion)
{
...
}