假设我已经读了很多关于版本一个RESTful API，因此我决定不通过URI版本的服务，但使用mediatypes（格式和架构在请求接受头）：
什么是执行WCF服务或Web API服务，以服务于接受的URI定义所请求的资源，格式（如应用程序/ JSON）和架构/版本（例如玩家-V2）请求的最佳方式头？
WCF允许我基于URI路径，但不是基于头。 所以我不能正确路由。
网页API可以让我定义自定义mediatypeformatters，路由请求的格式，而不是架构（例如，返回类型PlayerV1或PlayerV2）。
我想实现一个服务（或者与WCF或Web API）其中，此请求（伪代码）：
api.myservice.com/players/123 Accept format=application/json; schema=player-v1
返回PlayerV1实体，JSON格式
与此请求：
api.myservice.com/players/123 Accept format=application/json; schema=player-v2
返回PlayerV2实体，JSON格式。
关于如何实现这个任何提示？
编辑 ：为了澄清我为什么要使用内容协商来处理的版本，在这里看到： REST API设计：将“类型”，在“内容类型” 。
你正在把这里不看我的版本，但它是更多的内容协商。 接受头表示对资源的格式客户的愿望。 服务器应授予愿望还是回到406。因此，如果我们需要更多的合同的概念（尽管Web API unline RPC没有定义），然后使用资源是比较扎实的。
对版本控制的最佳实践还没有充分讨论，但大多数REST爱好者相信在网址中使用的版本是要走的路 （如http://server/api/1.0.3/... ）。 这在你的做法也让我更有意义，因为使用内容协商服务器，以保持向后兼容性，我只能想象在服务器上的代码就会变得越来越复杂。 使用URL的方式，你可以一刀两断：老客户能愉快地使用以前的，而新客户可享受新的API带来的好处。
UPDATE
OK，现在的问题已经改为“以RESTful AP实现内容协商”。
类型1：控制器，健忘
基本上，如果内容协商涉及到资源的唯一格式，实施或使用正确的媒体类型格式化就足够了。 例如，如果内容协商涉及返回JSON或XML。 在这种情况下， 控制器是健忘的内容进行谈判。
类型2：控制器感知
控制器需要知道请求协商。 在这种情况下，需要从该请求中提取，并通过在作为参数从请求参数。 例如，假设一个控制器上这个动作：
public Player Get(string schemaVersion)
{
...
}
在这种情况下，我会用经典的MVC样式值提供商（参见Brad Wilson的职位上ValueProviders -这是对MVC的Web，但API的价值提供类似于）：
public Player Get([ValueProvider(typeof(RequestHeadersSchemaValueProviderFactory))]string schemaVersion)
{
...
}
