REST api版本控制(仅对表示进行版本控制，而不是资源本身)
我看过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')。
你认为如何？在哪些事情上你会不同意/同意？
回答 5
Stack Overflow用户
发布于 2010-01-08 23:27:15
我完全同意；URI表示身份，当引入新版本时，身份不会改变。当然，可能会有新的URI用于其他概念，并且现有的URI可能会重定向…但是在URI中包含"v2“对我来说就像是RPCish。
请注意，这与REST没有任何关系，实际上，从REST的角度来看，它只是字符。
Stack Overflow用户
发布于 2010-01-08 11:29:06
不管怎么说，我同意你的观点，曼纽尔。你可以在这个问题中看到我的推理How to version REST URIs
似乎有很多人不同意，但我不会担心。只要你尊重超文本约束，你的url看起来就不会对你的客户端产生太大的影响。
Stack Overflow用户
发布于 2010-08-11 20:52:21
另一种方法可能是说“一个表示有多个API”：
http://xxx/user/123/api/1.json如果您愿意，您可以在请求时使用最新的API返回表示，如下所示：
http://xxx/user/123.json就我个人而言，我更喜欢其他解决方案，但这是另一种我还没有在这里看到建议的方法。
https://stackoverflow.com/questions/2024600
复制相似问题