Nik*_*hev 1 api project-planning compatibility specifications
我现在正在为我们产品的开发人员功能API工作.
第一个版本发布,目前用户数量很少.自从我开始开发第二个版本以来,一些部件被重新设计,一些部件被移除以使API更加优雅和清晰.
但是第二版部署对于旧版本用户来说可能是一种痛苦.我们的营销部门正计划大量增强我们的API产品,为其添加更多功能.
我应该如何构建系统,
1)我们不会受限于"旧版本"添加新的有趣功能
2)当前的API用户不会不满意,因为需要重新设计他们的系统以符合更改的API
或者,如果API产品在公开发布之前的相当长的一段时间内在沙箱中进行测试,那么规范中是否会有任何重大修改？
当您必须对已经拥有某些用户的API进行更改时,最好的方法是弃用旧的API调用并鼓励使用新的调用.
删除旧API调用的功能可能会破坏旧代码的功能,因此可能会导致一些使用"旧"API的开发人员变得有点不满意.
如果您的语言提供了表明某些功能已被弃用的方法,则它可以作为用户停止使用旧API调用并转换为新调用的指示.在Java中,@deprecatedjavadoc标记可以在文档中提供已弃用功能的@Deprecated注释,或者从Java 5开始,注释可用于在调用不推荐使用的API功能时引发编译时警告.
此外,提供从旧API迁移到新API的一些提示和提示可能是一个好主意,以鼓励人们使用与API交互的新方式.有关做什么和不做什么的示例和示例代码,API的用户将能够根据新的首选方式编写代码.
改变公共API会很困难,但是在从旧到新的过渡中需要特别注意,我相信在一定程度上可以减轻对API用户造成的痛苦.
这是一篇关于如何以及何时从Sun 弃用API的文章,它可能提供有关何时适合弃用部分API的更多信息.
另外,感谢David Schmitt,他补充说.NET 中的Obsolete属性类似于@DeprecatedJava中的注释.(不幸的是编辑被我的编辑覆盖了,因为我们都在同时编辑这个答案.)