REST api版本控制（仅版本表示，而不是资源本身）
我看了一下API版本的最佳实践？ ，但是我不太相信答案，所以我再次以更具体的例子来质疑版本控制部分。 我有两个URI（一个版本是URI的一部分，另一个没有）：
http://xxxx/v1/user/123 -> favored solution in discussed thread http://xxxx/user/123 我怀疑第一个链接是否expression了REST的想法。 我发现http://xxxx/v1/user/123令人困惑，因为它暗示有一天会有一个更高的api版本，像http://xxxx/v2/user/123 。 但是这在REST术语中没有意义，api版本本身就是HTTP 1.0或1.1，它已经在HTTP请求中发送了。 这个以REST资源为中心的视图与其他api接口（如SOAP或Java接口（通常在限定名称中包含api-versions））之间的差别很大。
在REST中，版本控制唯一有意义的是该资源的表示（例如添加或删除新的字段）。 这个版本控制属于内容协商的部分，如：
http://xxx/user/123 + HTTP 'Accept' Header -> Content negotation through header http://xxx/user/123?v=1 -> for perma-links/hyperlinks
人们也可以争辩说，这样的版本内容协商可能是path中的URI的一部分，但是我觉得它是违反直觉的，因为你可能以同一资源的不同的URI结束，并且必须在某个时刻保持redirect。
综上所述：在REST URI中没有api版本化，只有资源表示的版本。 表示版本信息属于内容协商（作为queryParam或HTTP“接受”）。
你怎么看？ 你会不同意/同意哪些事情？
我完全同意; 一个URI表示身份，当引入一个新的版本时身份不会改变。 当然，可能有新的URI用于附加的概念，现有的URI可能会redirect，但在URI中包含一个“v2”给我感觉RPCish。
请注意，这与REST无关，实际上，从RESTangular度来看，它们都只是字符。
您可以侦听X-API-Version HTTP请求标头。 如果头部存在，则服务器必须使用该版本的API。 如果标题不存在，服务器可能会使用最新版本的API。
> GET /user/123 HTTP/1.1 > Host: xxx > X-API-Version: >=1.5.1, <2.0.0 > Accept: application/json > < HTTP/1.1 200 OK < X-API-Version: 1.6.12 < < { "user": { "id": 123, "name": "Bob Smith" } } <
为了什么是值得的，我同意你的看法。 你可以在这个问题中看到我的推理如何版本REST URI
有很多人似乎不同意，但我不会担心。 只要你尊重超文本约束，你的url看起来真的不会对你的客户产生很大的影响。
我同意你不希望在API中显示的资源的URI中看到版本。 这使他们不“酷”。 也同意，这是表示最有可能改变。
然而，当你改变一个特定表示的内容时，会引发这个问题。 例如，如果你原来的frobnitz JSON表示是
{"x": "bam", "y": "hello"}
并且您想要添加一个“z”字段，您可能会觉得客户端应该已经意识到我们现在处于某种数据scheme的第2版。
对此我不确定。 我想你有几个select：
- 让您的客户面对一个轻微变化的交涉灵活。 在上面的例子中，我们仍然在生成一个JSON字典。
- 如果必须的话，在表示本身中放置一个版本（本例中是一个版本字段）。 通过这样做，您可以有效地在JSON内容types中声明子表示。 我认为这是相当有限的。
- 使用你自己的MIMEtypes和版本：application / x-my-special-json1.0，application / x-my-special-json1.1。 这允许您独立于彼此版本您的表示。 再次，这个你正在对你的客户做出重大的要求，以了解发生了什么事情。
总的来说，我认为你想优化你的API和你没有发明自己的客户的陈述; 其他人会在发现你的资源时创build的。 我相信，即使是在制作一些私有的东西的情况下，这也是有用的，因为它build立在一个有用的devise约束上，这将有助于使您的系统更加健壮。
我发现http：// xxxx / v1 / user / 123令人困惑，因为它暗示有一天会有更高的api版本，比如http：// xxxx / v2 / user / 123
这并不意味着 – 但是你将来有这种能力。
但是这在REST术语中没有意义，api版本本身就是HTTP 1.0或1.1，它已经在HTTP请求中发送了。
您的API的版本和您用来发出请求的HTTP版本不必相同。
人们也可以争辩说，这样的版本内容协商可能是path中的URI的一部分，但是我觉得它是违反直觉的，因为你可能以同一资源的不同的URI结束，并且必须在某个时刻保持redirect。
可以将版本作为URI参数进行演示。
用于perma-links / hyperlinks的http：// xxx / user / 123？v = 1 – >
另一种方法可以说“一个表示具有多个API”：
http://xxx/user/123/api/1.json
如果您愿意，可以在请求这样的情况下使用最新的API返回表示forms：
http://xxx/user/123.json
就我个人而言，我更喜欢其他的解决scheme，但这是另一种我还没有看到的方法。
对于REST，大部分答案忘记的是数据元素。 我假设多个版本的API仍然共享相同的数据层。 这意味着数据层迫使您以向后兼容的方式思考。 只有当您的API以向后兼容的方式进行更改时，才能做大的更改。 实际上，这意味着其他属性会悄悄地添加到您的实体，同时在您的API文档中使用按date弃用来指示什么时候会被删除。 理想情况下，您使用的注册scheme与您的API密钥用户的电子邮件地址，所以你可以通知他们在一定范围内（Facebook）的弃用。所以，我不认为你需要指定一个版本的任何地方。
