我在http://example.com/v1/SomeResource部署了一个 RESTful Web 服务。有一天，一个新的协议版本（不向后兼容）被部署到http://example.com/v2/SomeResource。从客户端的角度来看，这种升级可能发生在两个 HTTP 请求之间的任何时间。
服务器如何向客户端表明它不再支持 v1 调用并且客户端应该升级到 v2？我可以使用适当的响应代码吗？
我想向客户提供以下信息：
我推荐彼得威廉姆斯的以下文章
最佳实践：
最好将版本控制保留在 URL 之外，并使新资源与旧资源向后兼容。
向后兼容：
如果您必须在 URL 中保留 v1，并且正在制作 v2 URL，那么您必须决定是要支持这两种格式，还是要废弃旧的 v1。如果您决定废弃旧的 v1，那么我建议为任何请求 v1 URL 的人返回 303 或 401。
使旧 URL 过时：
我建议使用 303 See Other。或者，如果没有关联的重定向，则使用 410 Gone。
303 查看其他
可以在不同的 URI 下找到对请求的响应，并且应该使用该资源上的 GET 方法来检索。此方法的存在主要是为了允许 POST 激活脚本的输出将用户代理重定向到选定的资源。新的 URI 不是原始请求资源的替代引用。303 响应不能被缓存，但对第二个（重定向）请求的响应可能是可缓存的。
不同的 URI 应该由响应中的 Location 字段给出。除非请求方法是 HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新 URI 的超链接。
注意：许多 HTTP/1.1 之前的用户代理不理解 303 状态。当与此类客户端的互操作性是一个问题时，可以使用 302 状态代码代替，因为大多数用户代理对 302 响应做出反应，如此处针对 303 所述。
记录一切：
要关心的主要事情是您选择返回的任何内容，只需将其记录在您的文档中即可。您可以决定您希望您的服务如何工作，其他想要使用它的人将遵循文档。
我认为你不应该首先这样做，但可能为时已晚。
URI 也应该是静态的，这样当资源更改或服务的实现发生更改时，链接保持不变。这允许添加书签。同样重要的是，在 URI 中编码的资源之间的关系保持独立于关系在其存储位置的表示方式。
来自文章RESTful Web 服务：基础知识。
我建议改用 301（301 永久移动）。阅读为什么。
希望它有所帮助，布鲁诺·菲格雷多