REST api 的语义版本控制？
Semantic versioning of REST apis?
我已经评估了 REST api 的许多版本控制模式（header、url、…）。到目前为止，最可靠的方法似乎是 url 选项：它与代理一起工作，并且不依赖于晦涩的模式，例如 dates for versioning.
现在，当我环顾四周时，每个使用基于 url 的方法的人似乎都在使用诸如 v1、v2 等版本。没有人使用次要版本，甚至没有人使用 semantic versioning.
这样的模式
这引发了一些问题：
- 你什么时候增加 REST 的版本号api（当然，你对它的更新比五年一次要多）？
- 如果你只是修复了一个错误，你可能不会增加版本号，但是你如何区分两个版本？
- 如果您使用非常 fine-granular 的方法，您最终会得到 很多 个需要并行托管的版本。你是怎么处理的？
换句话说：像 GitHub 这样的公司如何在今天（2015 年）只有 v3，而他们已经经营了 7 年了？这是否意味着他们实际上只更改了 api 两次？我简直不敢相信。
有什么提示吗？
Web 服务只需要主版本号。因为您的消费者只关心向后不兼容的更改，并且（如果您正确遵循语义版本控制）这些更改只会在发布新的主要版本时引入。
所有其他更改（包括新功能、错误修复、补丁等）应该 'safe' 供您的消费者使用。这些新功能 没有 供您的消费者使用，您可能不想再继续 运行 包含错误 X 或 Y 的未修补版本不必要的。
在您的 URL 中使用完整的版本号（或您用于 API 版本控制的任何方法）实际上意味着您的消费者必须更新您的 URL =23=] 每次你对 API 进行更新/错误修复时，他们会继续使用未打补丁的版本，直到他们这样做。
当然，这并不意味着您不能在内部使用语义版本控制！只需使用第一部分（主要版本）作为 API 的版本号。在你的 URL / header / 其他版本控制系统中包含完整的版本号是没有意义的。
所以回答你的问题：你每次发布新版本时都会更新你的API，但是只有当你有一个新的主要版本时你才会发布一个新的API版本。这样你只需要托管几个不同的版本（当然你可以随着时间的推移弃用旧版本）。
我已经评估了 REST api 的许多版本控制模式（header、url、…）。到目前为止，最可靠的方法似乎是 url 选项：它与代理一起工作，并且不依赖于晦涩的模式，例如 dates for versioning.
现在，当我环顾四周时，每个使用基于 url 的方法的人似乎都在使用诸如 v1、v2 等版本。没有人使用次要版本，甚至没有人使用 semantic versioning.
这引发了一些问题：
- 你什么时候增加 REST 的版本号api（当然，你对它的更新比五年一次要多）？
- 如果你只是修复了一个错误，你可能不会增加版本号，但是你如何区分两个版本？
- 如果您使用非常 fine-granular 的方法，您最终会得到 很多 个需要并行托管的版本。你是怎么处理的？
换句话说：像 GitHub 这样的公司如何在今天（2015 年）只有 v3，而他们已经经营了 7 年了？这是否意味着他们实际上只更改了 api 两次？我简直不敢相信。
有什么提示吗？
Web 服务只需要主版本号。因为您的消费者只关心向后不兼容的更改，并且（如果您正确遵循语义版本控制）这些更改只会在发布新的主要版本时引入。
所有其他更改（包括新功能、错误修复、补丁等）应该 'safe' 供您的消费者使用。这些新功能 没有 供您的消费者使用，您可能不想再继续 运行 包含错误 X 或 Y 的未修补版本不必要的。
在您的 URL 中使用完整的版本号（或您用于 API 版本控制的任何方法）实际上意味着您的消费者必须更新您的 URL =23=] 每次你对 API 进行更新/错误修复时，他们会继续使用未打补丁的版本，直到他们这样做。
当然，这并不意味着您不能在内部使用语义版本控制！只需使用第一部分（主要版本）作为 API 的版本号。在你的 URL / header / 其他版本控制系统中包含完整的版本号是没有意义的。
所以回答你的问题：你每次发布新版本时都会更新你的API，但是只有当你有一个新的主要版本时你才会发布一个新的API版本。这样你只需要托管几个不同的版本（当然你可以随着时间的推移弃用旧版本）。