假设您正在开发一个平台，该平台为用户提供基于 Web 的界面，并为第三方开发人员提供 API。类似于 Salesforce(甚至 Facebook)。
Salesforce 和 Facebook，这两个平台都为其用户提供正常的基于 Web 的界面，并为第三方开发人员提供 API。
理想情况下，任何 API 都会在内部调用基于 Web 的界面所使用的相同函数。例如“创建项目”按钮和“CreateProject”API 在内部调用相同的“createProject()”函数。因此，您可以为两者维护相同的版本，因为在大多数情况下它们是紧密集成的。
现在，有时您添加的功能会增加基于 Web 的界面的次要版本，但由于您没有在 API 中实现该功能，因此 API 版本应保持不变。
您如何处理此类情况？您是否应该为您的平台维护单独版本的基于 Web 的界面和 API？
最佳答案
视情况而定。因为很难为这个问题提供结论性的答案。但我会分享一些想法并深入研究一些场景，以提供最好的帮助。
我建议应该有两个版本的 API。 内部 API 和公共(public) API。在调用者端，它们将是两个物理上不同的 api/端点，以便可以在不暴露太多信息的情况下完成安全策略和许多其他事情，也不需要在代码上中继任何责任来处理基于区分策略的代码。谁从哪里打电话，因为这可能很容易失败。
如果两个版本的 api 在某种程度上进行整合，而不涉及任何安全风险，但一个单独的专家工程师团队可以将这种整合设计得无缝且安全。这是代码重用和其他一切之间的权衡。这是非常主观的，可能会变成无休止的讨论。但是，如果软件是敏捷和迭代的，那么由于这种设计过程，软件会发展得很好。
API 应可外部化且可互操作。如果项目非常大，那么处理项目不同部分的不同团队将仅使用内部 API 来交互彼此的工作。没有任何花招。没有直接的数据访问。仅 API。
如果 api 是可发现的，这种方法将帮助您了解所有团队在项目中所做的事情，我个人认为这对于团队协作来说是一件非常好的事情。事实上，它也有助于可重用性。测试变得统一和自动化。每个团队都会对自己的工作负责，因此应该很容易解决责任问题。
还有更多的东西可以放在这里，但我认为这在高层次上已经足够了。
如果允许，我也会将此问题读作
"Should you have purely service oriented architecture or not ?"
我的答案是，**这要看情况。**因为很难对此提供结论性的答案......
关于api - 您是否应该维护基于 Web 的界面和 API 的单独版本号？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24570928/