在设计确保向后兼容性和新版本发布的API时,有什么最佳实践需要记住。任何链接到文章/博客表示赞赏。确保向后兼容性的API设计
回答
你应该看看这个演示约API设计。它来自Google,非常好。 它还解决了向后兼容性和新版本。
都保持运转,用版的网址。 api.mysite.com/[version]/api/url/here
。在API的新版本到达时通知用户,并在一段时间后删除旧版本。无论什么时候不再使用,或者6个月,确保用户有足够的时间来改变它。
或保持运行下去,但是没有为其提供任何新的功能。
这基本上是我在多个项目中使用的方法。我经常见到的另一种模式是让'api.example.com /'指向最新版本的API - 注意缺少版本号。不想要最新和最好的客户端可以免费访问版本控制的URL - 'api.example.com/v1 /' – Anurag 2012-01-18 09:07:58
有一些讨论,如果您在url方案中包含版本控制,是否仍然可以将其称为REST api 。请参阅http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven或http://thereisnorightway.blogspot.com/2011/02/versioning-and-types-in-resthttp -api.html – 2012-01-18 09:18:16
谢谢。这些更接近版本化API和部署这些API。我想知道,如果有关于如何公开API的,如果你的数据架构更改会发生什么情况的任何指引(删除/修改某些数据类型,其通过公开的API的等) – Sampat 2012-01-18 09:22:43
最好的方式做到这一点,以保持在新版本中的新接口和类旧的接口或类以及它们标记为弃用(指那些将在未来版本中删除)。
听API设计师牢记关于公共接口和发布接口之间的差异。
- 1. 设计新API但保持兼容性
- 2. 向后兼容性材质设计
- 3. 如何确保URL重写后的向后兼容性?
- 4. 为了支持向后兼容性,明确设计了哪些Java设计?
- 5. 正确的向后兼容性,java.lang.VerifyError
- 6. iOS 6 API和向后兼容性
- 7. aspnet-api-versioning - 向后兼容性
- 8. Android地图API v2向后兼容性
- 9. Android:如何保持向后兼容性?
- 10. CUDA计算能力向后兼容性
- 11. 确保动态加载类型的向后兼容性
- 12. C#的向后兼容性
- 13. DirectX的向后兼容性
- 14. 前L版本的材料设计向后兼容性Android
- 15. SYSTEM_UI_FLAG_IMMERSIVE_STICKY向后兼容性
- 16. .net 4向后兼容性
- 17. visual studio向后兼容性
- 18. GCC向后兼容性
- 19. VSTO 2012:向后兼容性
- 20. pandas.DataFrame.to_pickle向后兼容性
- 21. 向后兼容性play-1.2.3
- 22. 插件向后兼容性
- 23. Xcode向后兼容性
- 24. WP7.1向后兼容性
- 25. XSD向后兼容性
- 26. 向后兼容性dll
- 27. UIRefreshControl向后兼容性
- 28. Spring 4.0.0向后兼容性
- 29. Silverlight 5向后兼容性
- 30. UWP MediaPlayerElement向后兼容性
http://lcsd05.cs.tamu.edu/slides/keynote.pdf <<断链:( – kinar 2016-05-17 19:10:42
,但仍然打破,也许这是一个?http://static.googleusercontent.com/media/research。 google.com/en//pubs/archive/32713.pdf – user180574 2016-07-01 19:32:06
链接已损坏 – Salar 2016-11-19 09:51:53