确保向后兼容性的 API 设计 [关闭]答案

【问题标题】：API design ensuring backward compatibility [closed]确保向后兼容性的 API 设计 [关闭]
【发布时间】：2012-02-13 00:25:19
【问题描述】：

在设计 API 以确保向后兼容性和新版本发布时，是否有任何最佳实践需要牢记。感谢任何文章/博客的链接。

【问题讨论】：

【解决方案1】：

您应该查看这个关于 API 设计的演示文稿。它来自谷歌，非常好。它还解决了向后兼容性和新版本问题。

【讨论】：

【解决方案2】：

保持两者运行，在 url 中有版本。 api.mysite.com/[version]/api/url/here。当 API 的新版本到来时通知用户，并在一段时间后删除旧版本。无论是不再使用它，还是像 6 个月一样确保用户有足够的时间来更改它。

或者让它永远运行，但不要为其提供任何新功能。

【讨论】：

这基本上是我在多个项目中使用的方法。我经常看到的另一种模式是让api.example.com/ 指向 API 的最新版本——注意缺少版本号。不想要最新最好的客户可以免费访问版本化 URL - api.example.com/v1/
如果您在 url 方案中包含版本控制，是否仍可以将其称为 REST api 存在一些讨论。见roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven或thereisnorightway.blogspot.com/2011/02/…
谢谢。这些更倾向于对 API 进行版本控制和部署。我很想知道是否有任何关于如何公开 API 的指南，如果您的数据架构发生变化（您删除/修改通过 API 公开的一些数据类型等）会发生什么
@Sampat 如果您喜欢某个答案（作为最佳答案），请这样标记
@Anurag 在您建议的方法中，如果我指向最新的并实施我的端点解决方案并且可能会在同一 URI 上发布您的新版本 API 并且您对当前版本进行版本活到 /vn/ 那么还有可能破坏端点吗？

【解决方案3】：

最好的方法是在新版本中保留旧接口或类，并使用新接口和类并将它们标记为已弃用（意味着这些将在未来版本中删除）。

听听 API 设计者注意公共接口和发布接口之间的区别。

【讨论】：