我应该如何增加PHP REST API的版本号？

Question

我在这里阅读了版本格式：Versioning

它将版本描述为： MAJOR.MINOR.PATCH （例如：1.12.3）

他们还写道：

  

次要和补丁版本：这些透明到客户端并使用   内部用于向后兼容的更新。

要了解透明的事情，我会阅读snailboat的回答here：

现在，我已经更改了我的API中的一些代码来修复错误并提高客户端的性能（android app ）。这也需要在客户端进行一些更改（应用程序中的一些更改）。

根据第一个链接，如果我当前的版本 2.0.0 ，我可以将其更新为 2.0.1 。但是他们还声明“这些对客户来说是透明的”这意味着应用不会需要进行任何更改（我明白了吗？我不确定。）< / p>

但根据第二个链接，snailboat引用了：

  

“对用户透明。”换句话说，用户喜欢   特定功能的好处，而不知道它是如何   完成“。

他强调用户/客户而不是客户。这意味着，用户没有看到任何变化，但这是否也意味着客户是否需要有些变化？

所以，我有点困惑，我的问题是：是否可以将我的API从2.0.0更新到2.0.1，保持透明度？如果是，谁不会受到影响：用户/客户或客户（app）？

PS：我需要增加版本以支持旧版应用。

Answer 1

您应该将内部API版本更新为2.0.1，但这不应反映在客户端使用API​​的方式中。

我们假设您将API版本存储为URL的一部分，类似于此http://api.com/api/2.0/，在进行修补程序更改时，您不应将其更改为http://api.com/api/2.0.1，因为这会破坏客户端的透明度使用API​​。

如果有人在移动应用中使用API​​，则需要在源代码中进行更改以反映更改，这不太理想。

对次要版本和/或主要版本进行更改时，更改应反映在API版本控制中。 这意味着客户需要对源代码进行更改，但这是可以的，因为小/主要的更改应该由消费者同意。

注意：您最终会支持API http://api.com/2.0 http://api.com/2.1的多个版本，依此类推。

Answer 2

我从许多不同的人那里学到了Semantic Versioning的基本经验法则：

1. 消费者需要更改实施：主要版本
2. 添加了新功能，消费者无需更改：次要版本
3. 错误修正，消费者无需更改：补丁

现在有一些警告，特别是在开发初期，几乎所有的变化都会产生一个主要版本。由您决定何时发布1.0.0版本。从那一刻开始，你绝对总是坚持语义版本。

如果我理解正确（“这也需要在客户端进行一些更改”），您需要碰到3.0.0。

编辑：见下图

透明度：使用/api/v2对消费者是透明的。他知道他在主要版本2上，这就是他需要知道的全部内容。如果您发布主要版本3并因此发布/api/v3，他可以决定是否更新。

在引擎盖下，当然你不断更新和修复api。那是内部版本控制以及我认为你的问题是关于什么的。在这里，您使用语义版本控制。消费者应该只关心主要版本。