问REST api版本控制(仅对表示进行版本控制，而不是资源本身)

EN

我看过Best practices for API versioning?，但不太相信答案，所以我用一个更具体的例子再次质疑版本控制部分。我有两个URI (一个将版本控制作为URI的一部分，另一个没有)：

http://xxxx/v1/user/123    -> favored solution in discussed thread
http://xxxx/user/123             

我怀疑第一个链接是否表达了REST的思想。我发现http://xxxx/v1/user/123令人困惑，因为它暗示有一天会有像http://xxxx/v2/user/123这样的更高版本的api。但这在REST术语中没有意义，api版本本身是HTTP 1.0或1.1，它已经在HTTP请求中发送。这种以REST资源为中心的视图与其他api接口有很大的不同，比如SOAP或Java接口(在这些接口中，通常在限定名中包含api版本)。

在静止状态下，版本控制唯一有意义的是资源的表示(例如，添加或删除新字段)。此版本控制属于内容协商的一部分，如：

http://xxx/user/123 + HTTP 'Accept' Header -> Content negotation through header
http://xxx/user/123?v=1                    -> for perma-links/hyperlinks

有人可能会争辩说，这样的版本内容协商可能是路径中URI的一部分，但我发现这是违反直觉的，因为您可能会为相同的资源使用不同的URI，并且在某些时候必须维护重定向。

总而言之:在REST URI中没有api版本控制，只有资源表示的版本控制。表示version-info属于内容协商(如queryParam或HTTP 'Accept')。

你认为如何？在哪些事情上你会不同意/同意？