使用WCF或ASP.Net Web Api实现RESTful API的版本控制

Question

假设我已经读了很多关于版本一个RESTful API,因此我决定不通过URI版本的服务,但使用mediatypes(格式和架构在请求接受头):

实现wcf服务或web api服务以提供定义uri中所请求资源的请求的最佳方式是什么,格式(例如,application/json)和schema中的schema/version(例如player-v2)头？

WCF允许我基于uri进行路由,但不基于标头.所以我不能正确路由.

Web Api允许我定义自定义mediatype格式,路由所请求的格式,但不是模式(例如,返回类型PlayerV1或PlayerV2).

我想实现一个服务(使用WCF或Web Api),对于此请求(伪代码):

api.myservice.com/players/123 Accept format=application/json; schema=player-v1

以json格式返回PlayerV1实体

并为此请求:

api.myservice.com/players/123 Accept format=application/json; schema=player-v2

以json格式返回PlayerV2实体.

有关如何实现这一点的任何提示？

编辑:为了澄清我为什么要使用内容协商来处理版本,请参见此处:REST API设计:将"类型"放在"内容类型"中.

Answer 1

在我看来，您带来的内容并不是版本控制，而是更多的内容协商。Accept 标头表达了客户端对资源格式的意愿。服务器应该满足愿望或返回406。因此，如果我们需要更多契约的概念（尽管Web API unline RPC没有定义契约），那么使用资源会更可靠。

版本控制的最佳实践尚未得到充分讨论，但大多数 REST 爱好者相信在 URL 中使用版本是正确的方法（例如http://server/api/1.0.3/...）。这对我来说也更有意义，因为在使用内容协商服务器的方法中必须保持向后兼容性，我只能想象服务器上的代码会变得越来越复杂。通过使用 URL 方法，您可以一刀两断：老客户可以愉快地使用以前的 API，而新客户可以享受新 API 的好处。

更新

好的，现在问题已更改为“在 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)
{
    ...
}