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

Posted 2023-03-07

【中文标题】您是不是应该维护基于 Web 的界面和 API 的单独版本号？

【英文标题】：Should you maintain separate version numbers of your web-based interface and APIs?您是否应该维护基于 Web 的界面和 API 的单独版本号？

【发布时间】：2014-08-25 14:15:41

【问题描述】：

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

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

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

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

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

【问题讨论】：

问题标题看起来更令人困惑，您将版本更新为软件版本号。愿您能得到更多专家的解答。

【参考方案1】：

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

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

这样可以实现代码的复用性，并且不会频繁增加公共API版本。

编辑：

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

【讨论】：

网页界面怎么样？您如何处理相同的版本控制？

【参考方案2】：

视情况而定。 因为很难对这个问题提供一个确凿的答案。但我会分享一些想法并深入研究一些场景以提供最好的帮助。

我建议应该有两个版本的 api。 内部 api 和 公共 api。在调用者端，它们将是两个物理上不同的 api/端点，因此可以在不暴露太多信息的情况下完成安全策略和许多其他事情，也无需在代码上传递任何责任来处理基于区分策略的区别关于谁从哪里打来的电话，因为这很容易失败。

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

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

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

这里有更多的东西可以加入，但我认为这在高层次上已经足够了。

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

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

而我的回答是，**视情况而定。**因为很难对此提供结论性的答案...

【讨论】：

感谢您的回答。您建议拥有 2 个版本的 API，但我问的是维护基于 Web 的界面和 API 的单独版本。您对此有何看法？