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

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

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

你带来什么并不是我的版本,但更多的是内容协商. Accept标头表示客户端对资源格式的愿望.服务器应该授予愿望或返回406.因此,如果我们需要更多的契约概念(尽管Web API unline RPC没有定义),那么使用资源更加可靠.

版本控制的最佳实践尚未完全讨论,但大多数REST爱好者认为使用URL中的版本是可行的方法(例如http：//server/api/1.0.3 / …).这对我来说也更有意义,因为在你的方法中使用内容协商服务器必须保持向后兼容性,我只能想象服务器上的代码会变得越来越复杂.使用URL方法,您可以彻底解决：旧客户可以愉快地使用以前,而新客户可以享受新API的好处.

UPDATE

好了,现在问题已经改为“在RESTful AP中实现内容协商”.

类型1：控制器 – 忘记

基本上,如果内容协商仅涉及资源的格式,则实现或使用正确的媒体类型格式化器就足够了.例如,如果内容协商涉及返回JSON或XML.在这些情况下,控制器无视内容协商.

类型2：控制器感知

控制器需要知道请求协商.在这种情况下,需要从请求中提取请求中的参数并将其作为参数传入.例如,让我们想象一下控制器上的这个动作：

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

在这种情况下,我会使用经典的MVC样式值提供程序(请参阅Brad Wilson’s post on ValueProviders – 这是在MVC上,但Web API的值提供程序看起来类似)：

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