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

Question

假设我已经阅读了很多有关 Restful api 版本控制的内容，并且我决定不通过 uri 对服务进行版本控制，而是使用媒体类型(请求接受 header 中的格式和架构):

实现 wcf 服务或 Web api 服务来服务在 uri、格式(例如 application/json)和架构/版本(例如 player-v2)中定义所请求资源的请求的最佳方式是什么在接受 header 中？

WCF 允许我根据 uri 进行路由，但不能根据 header 进行路由。所以我无法正确路由。

Web Api 允许我定义自定义媒体类型格式化程序、请求格式的路由，但不能定义架构(例如返回类型 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 Design: Put the “Type” in “Content-Type” .

Answer 1

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

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

<小时/>

更新

好的，现在问题已更改为“在 RESTful AP 中实现内容协商”。

类型 1:忽略 Controller

基本上，如果内容协商仅涉及资源的格式，则实现或使用正确的媒体类型格式化程序就足够了。例如，如果内容协商涉及返回 JSON 或 XML。在这些情况下，控制者不会注意到内容协商。

类型 2: Controller 感知

Controller 需要了解请求协商。在这种情况下，需要从请求中提取请求中的参数并将其作为参数传入。例如，让我们想象一下 Controller 上的此操作:

public Player Get(string schemaVersion)
{
    ...
}

在这种情况下，我将使用经典的 MVC 样式值提供程序(请参阅 Brad Wilson's post on ValueProviders - 这是在 MVC 上，但 Web API 的值提供程序看起来相似):

public Player Get([ValueProvider(typeof(RequestHeadersSchemaValueProviderFactory))]string schemaVersion)
{
    ...
}