我有一个RESTful Web服务部署在http://example.com/v1/SomeResource。有一天，一个新的协议版本（不向下兼容）部署到http://example.com/v2/SomeResource。从客户端来看，这种升级可能发生在两个HTTP请求之间的任何时候。版本控制RESTful服务？
服务器如何向客户端指示不再支持v1调用，并且客户端需要升级到v2？有没有适合我使用的回应码？
我想提供以下信息客户端：
最佳实践：
它可能会更好，以保持版本出来的URL，并作出新的资源后向兼容旧的兼容。
向后兼容：
如果你必须保持V1的URL，并正在V2的URL，那么你必须决定是否要支持这两种格式，或使旧V1过时。如果您决定让旧版v1过时，那么我建议您为请求v1网址的任何人返回303或401。
使旧网址已过时：
我会建议使用303查看其它。或者如果没有关联重定向，则使用410 Gone。
303查看其它
于所述请求的响应可以根据不同的URI被 发现并且应该 使用GET方法上 该资源进行检索。此方法主要用于允许 POST激活的脚本的输出将 用户代理重定向到选定的资源。对于最初请求的资源，新的URI不是替代参考 。 不得高速缓存303响应， ，但对第二个 （重定向）请求的响应可能是可缓存的 。
不同的URI应该由 响应中的位置字段给出。 除非请求方法是HEAD， 响应的实体SHOULD 包含一个短超文本注释和一个 超链接到新的URI。
注意：许多pre-HTTP/1。1个用户代理不了解303 的状态。当与这样的客户的互操作性是一个问题，在 302状态码可以替代地使用，因为大多数用户代理如这里描述的用于303
文献一切反应 到302响应：
主要关心的是您选择返回的任何内容，只需在文档中记录它即可。你可以决定你的服务如何工作，其他想要使用它的人会遵循文档。
我想你不应该摆在首位做到这一点，但可能为时已晚。
的URI还应该是静态的，这样 当资源的变化或 实施服务变更， 链接保持不变。这允许 书签。同样重要的是，在URI中编码的资源 之间的关系仍然是 ，而与 关系被表示的方式无关，其中 被存储。
是的，在一个理想的世界中，你会是对的，但我正在谈论当你不得不打破向后兼容性时该怎么做。如果我可以保持向后兼容性，那么我会尽量保持你所建议的相同的URI。 – Gili 2008-11-11 19:45:39
我推荐下面的文章由彼得·威廉姆斯
对于它的价值，我觉得达雷尔的帖子（在一个单独的问题）是启发：http://stackoverflow.com/questions/972226/how-to-version-rest-uris/975394＃975394 – Gili 2010-02-23 04:39:57
[API版本控制的最佳实践？]的可能重复（https://stackoverflow.com/questions/389169/best-practices-for-api - 版本） – Helen 2017-10-10 22:45:46