我已经为REST apis（header，url，...）评估了许多版本控制模式。到目前为止，最可靠的方法似乎是url选项：它适用于代理，并且不依赖于dates for versioning等模糊的模式。
现在，当我环顾四周时，使用基于网址的方法的每个人似乎都使用v1，v2等版本。没有人使用次要版本，甚至是semantic versioning等模式。
这提出了一些问题：
换句话说：GitHub这样的公司，如今只有v3今天（2015年），他们现在已经有7年了？这是否意味着他们实际上只改变了他们的api两次？我简直不敢相信。
任何提示？
答案 0 :(得分：26)
主要版本号是Web服务所需的全部内容。因为您的消费者只关心向后不兼容的更改，并且（如果您正确地遵循语义版本控制），那么只有在发布新的主要版本时才会引入这些更改。
所有其他更改（包括新功能，错误修正，补丁等）应该是“安全的”＃39;为您的消费者。这些新功能不会让您的消费者使用，并且您可能不希望继续运行包含错误X或Y的未修补版本超过必要的时间。
使用您网址中的完整版本号（或您用于API版本控制的任何方法）实际上意味着您的消费者每次对API进行更新/修正时都必须更新API的网址，并且他们会保留使用未修补的版本，直到他们这样做。
这并不意味着你当然不能在内部使用语义版本控制！只需使用第一部分（主要版本）作为API的版本号。在您的URL /标题/其他版本控制系统中包含完整版本号是没有意义的。
因此，要回答您的问题：每次制作新版本时都会更新API，但只有在拥有新主要版本时才会发布新的API版本。这样您只需托管几个不同的版本（当然，您可以随着时间的推移弃用旧版本。）