您是否应该维护基于Web的界面和API的单独版本号？

Question

假设您正在开发一个平台，该平台为其用户提供基于Web的界面，为第三方开发人员提供API。与Salesforce（甚至是Facebook）类似的东西。

Salesforce和Facebook，两个平台都为其用户提供了基于Web的界面，为第三方开发人员提供了API。

理想情况下，任何API内部调用基于Web的界面使用的相同功能。对于例如“创建项目”按钮和“CreateProject”API在内部调用相同的“createProject（）”函数。因此，您可以为两者保持相同的版本，因为在大多数情况下，它们是紧密集成的。

现在，有时您添加一项功能，可以增加基于Web的界面的次要版本，但由于您未在API中实现该功能，因此API版本应保持原样。

你如何处理这类案件？您是否应该为您的平台维护基于Web的界面和API的单独版本？

Answer 1

取决于此。因为很难对这个问题提供确凿的答案。但我会分享一些想法，深入研究一些场景，以便充分发挥作用。

我建议应该有两个版本的api。 内部apis 和 public apis 。在呼叫者端，它们将是两个物理上不同的api /端点，因此安全策略和许多其他事情可以在不暴露大量信息的情况下完成，并且不会在代码上转移任何责任来处理基于区分策略关于谁在哪里打电话可能很容易失败。

如果apis 的两个版本在某种程度上合并而不涉及任何安全风险，则可以，但是专家工程师的单独团队可以将此合并设计为无缝且安全。这是代码重用和其他一切之间的权衡。这是非常主观的，可以变成无休止的讨论。但是，如果软件具有敏捷性和迭代性，那么该软件的设计过程就会非常好。

apis应该是可外部化和可互操作的。如果项目非常大，那么在项目的不同部分工作的不同团队将仅使用内部apis与彼此的工作进行交互。没有手帕。没有直接的数据访问。只有apis。

如果apis可被发现，这种方法将帮助您了解所有团队在项目中所做的工作，我个人认为这对团队协作工作来说是一件非常好的事情。事实上，它也有助于重复使用。测试变得统一和自动化。每个团队都将对自己的工作负责，因此应该很容易解决问责制。

这里有更多东西可以进入，但我认为这在高水平已经足够了。

如果允许，我也会将此问题视为

  

“你是否应该拥有纯粹的服务导向架构？”

我的答案是，**它取决于。**因为很难为此提供一个确定的答案......

Answer 2

不要直接通过API发布核心功能，而是将所有API函数创建为代理函数，核心函数的所有更改都将在代理函数中处理。

如果API输入/输出发生更改，请更改公共API版本。

通过这种方式，您可以实现代码重用性，并且不会频繁增加公共API版本。

修改

如果您在谈论软件版本号。我的回答是肯定的。