假设您正在开发一个平台，该平台为其用户提供基于 Web 的界面，并为第三方开发人员提供 API。类似于 Salesforce（甚至 Facebook）的东西。
Salesforce 和 Facebook，这两个平台都为其用户提供基于 Web 的正常界面，并为第三方开发人员提供 API。
理想情况下，任何 API 在内部调用基于 Web 的界面所使用的相同函数。例如，“创建项目”按钮和“CreateProject”API 在内部调用相同的“createProject()”函数。因此，您可以为两者保持相同的版本，因为在大多数情况下它们是紧密集成的。
现在有时您添加一个功能，使您增加基于 Web 的界面的次要版本，但由于您没有在 API 中实现该功能，因此 API 版本应该保持原样。
您如何处理此类案件？您是否应该为您的平台维护基于 Web 的界面和 API 的单独版本？
这取决于。因为这个问题很难给出一个确定的答案。但我会分享一些想法并深入研究一些场景以提供最好的帮助。
我建议应该有两个版本的api。内部 API和公共 API。在调用者端，它们将是两个物理上不同的 api/端点，因此可以在不暴露太多信息的情况下完成安全策略和许多其他事情，也无需在代码上传递任何责任来处理基于区分策略的区别关于谁从哪里打来的电话，因为这很容易失败。
如果两个版本的 api在某种程度上整合到一定程度而不涉及任何安全风险，但一个单独的专家工程师团队可以将这种整合设计为无缝且安全的，这是可以的。这是代码重用和其他一切之间的权衡。这是非常主观的，可能会变成无休止的讨论。但是，如果软件是敏捷和迭代的，那么这个设计过程的结果就会很好地发展。
api 应该是可外部化和可互操作的。如果项目非常大，那么从事项目不同部分的不同团队将仅使用内部 API 与彼此的工作进行交互。没有手帕。没有直接的数据访问。只有api。
如果 api 是可发现的，这种方法将帮助您了解所有团队在项目中所做的事情，我个人认为这对于协作团队工作是一件非常好的事情。事实上，它也有助于重用性。测试变得统一和自动化。每个团队都将对自己的工作负责，因此应该很容易解决问责制。
这里有更多的东西可以放进去，但我认为这在高层次上就足够了。
如果允许，我也会将这个问题读作
“您是否应该拥有纯粹的面向服务的架构？”
我的回答是，**这取决于。**因为很难对此提供一个确凿的答案......
不要直接通过 API 发布核心函数，而是将所有 API 函数创建为代理函数，核心函数的所有更改都将在代理函数中处理。
如果 API 输入/输出发生变化，请更改公共 api 版本。
这样你就可以实现代码的可重用性，并且不会频繁增加公共 API 版本。
编辑：
如果您在谈论软件版本号。我的回答是肯定的。