从环顾四周,似乎有两种方法可以解决.或者创建一个API区域,并且具有返回json / xml的控制器.或者使用动作过滤器和单个前端控制器,并根据请求头返回json / xml / html.
我想做晚些时候,但是我想知道如果你去这条路线,你可以如何去版本化你的api？
如果你去第一条路线,你可以很容易地创建一个v1 / v2控制器,但如果你以后做,你怎么可以版本呢？
解决方法
>网址.在这种情况下,假设https://api.example.com/v1/projects是与http://api.example.com/v2/projects不同的资源,尽管不是这样. Basecamp似乎这样做.按照这种方法,假设你总是必须支持旧的API.
>标题这些URL保持不变,但是,客户端会传递一个附加的HTTP标头,每个请求的X-MYAPI-VERSION都带有一个标识要使用的API版本的值. Google Documents List API这样做.这种方法的一个潜在问题是HTTP头可能会被客户端和服务器之间的中介剥离.
>参数.为了规避选项2的问题,您可以传递API版本作为参数(如https://api.example.com/projects?v=3).
>媒体类型.这里您的网址保持不变,用户需要使用accept和content类型标头来指定资源的表示.例如,可以使用“application / vnd.mycompany.resource [-version] [format]”来表示“project”,其中给出了对于v1 json或“application / vnd.mycompany.project-v1 json”的表示形式,vnd.mycompany.project-v1 xml“for v1 xml.当您需要一个新版本的项目时,mime类型可能会如下所示“application / vnd.mycompany.project-v2 xml”. Github似乎支持.
>部分有效载荷.在这种情况下,请求的有效载荷包含要使用的版本号.例如,当传递XML时,您可以查看命名空间来确定正在使用哪个版本的API.对于JSON,您可以使用“$version”或“_version”属性来指定版本.
>客户端密钥.当应用程序注册时,它指定要使用哪个版本的API.当您验证客户端时,确保您模拟了要使用的版本.
>没有明确的版本控制总是有一个选项,不要版本你的API,并尝试通过使所有的字段可选,透明地处理变更,并在缺少时适当地处理它们.有可能你会做这个,无论如何,使您的API的未来版本与您今天开发的版本兼容.
许多推荐选项4,虽然它并不总是实用.大多数这些选项需要额外的工作才能使用ASP.NET MVC.
