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