版本化RESTful服务？

Question

我在http://example.com/v1/SomeResource部署了一个RESTful Web服务。有一天，新的协议版本（不向后兼容）部署到http://example.com/v2/SomeResource。从客户端看，此升级可能在两个HTTP请求之间的任何时间发生。

服务器如何向客户端表明它不再支持v1调用，并且客户端应该升级到v2？我可以使用适当的响应代码吗？

我想向客户提供以下信息：

1. 发生了不兼容的升级。客户端无法使用新服务，因为协议可能完全不同。
2. 新客户端软件的URL。
3. 向用户解释他们必须升级的消息。

Answer 1

我推荐Peter Williams的以下文章

• Versioning REST Web Services

Answer 2

最佳做法：

最好将版本控制保留在URL之外，并使新资源向后兼容旧版本。

向后兼容：

如果您必须将v1保留在URL中，并且正在制作v2 URL，那么您必须决定是否要支持这两种格式，或者使旧的v1过时。如果您决定使旧的v1过时，那么我建议为请求v1 URL的任何人返回303或401.

旧网址已过时：

我建议使用303见其他。或者，如果没有关联的重定向，则使用410 Gone。

Source

  

303见其他

     

对请求的响应可以是   在不同的URI下找到并且应该   使用GET方法检索   那资源。这种方法存在   主要是为了允许输出a   POST激活的脚本重定向   用户代理到选定的资源。该   新URI不是替代参考   对于最初请求的资源。   303响应绝不能被缓存，   但对第二个的回应   （重定向）请求可能是   缓存。

     

不同的URI应该由。给出   响应中的“位置”字段。   除非请求方法是HEAD，   响应的实体应该   包含一个简短的超文本注释   指向新URI的超链接。

     

注意：许多pre-HTTP / 1.1用户代理不理解303     状态。当与这样的客户端的互操作性是一个问题时，     因为大多数用户代理会做出反应，所以可以使用302状态代码     如此处针对303所述的302响应。

记录所有内容：

要注意的主要问题是您选择退回的内容，只需在文档中记录即可。您可以决定服务的工作方式，其他想要使用它的人也会遵循文档。

Answer 3

我认为你不应该首先这样做，但可能为时已晚。

  

URI也应该是静态的   当资源发生变化时   实施服务变更，   链接保持不变。这允许   书签。这也很重要   资源之间的关系   在URI中编码的内容仍然存在   独立的方式   关系代表在哪里   它们被存储起来。

来自文章RESTful Web services: The basics。

Answer 4

我建议使用301（301 Moved Permanently）。阅读why。

希望它有所帮助， Bruno Figueiredo