我有一个面向公众的REST API和SDK，管理着多个资源：/ api / v1 / foo和/ api / v1 / bar。两者目前都是版本1.
我想对两个端点进行一些重大更改，包括使它们更加一致（标题，日期格式等），但由于我在敏捷环境中工作，我将对一个端点进行更改，释放它，然后更改另一个后来。 （假设foo首先得到增强）
我应该如何处理端点的版本控制？版本控制的不同选项有哪些优缺点？除了这些之外还有其他选择吗？
选项1：
发布/ api / v2 / foo并进行新的更改。保留/ api / v1 / foo和/ api / v1 / bar。想要使用/ api / v2 / foo的新功能的消费者会将对foo的API请求发送到/ api / v2 / foo，而对bar的请求仍然会被发送到/ api / v1 / bar。有些请求是v1，有些则是v2。
最终我释放/ api / v2 / bar并且消费者完全从v1过渡到所有请求都是v2。
选项2：
使用新更改发布/ api / v2 / foo。同时，我还发布了/ api / v2 / bar，这只是/ api / v1 / bar的别名。需要新功能的消费者不再需要使用v1 SDK并将其替换为v2 SDK。所有请求都以v2发送。
最后，当我完成条形码API的增强功能时，我会按照上面的相同过程将所有内容更改为v3。
答案 0 :(得分：1)
我更喜欢选项2.由于您正在对API进行版本控制而不是仅使用某些方法，因此从我的观点来看，这种方法似乎更加一致。作为开发人员，我认为，我不希望调用相同API的不同版本。
如果我选择切换到v2，我可以根据发布说明确定foo已更改并相应地更新我的应用程序。我仍然可以用相同的方式调用吧，因为它还没有改变，我不必考虑我需要使用API v1调用bar和其他所有内容，并且只需通过v2调用foo。
一旦你发布v3，你就明确说明这个新版本的栏已经改变了，我也会处理这些更改。
如果您想到应用程序，桌面应用程序或库，每当发生新的更改时，您也会增加整个应用程序的版本号。用户或开发人员也可以同时使用一个版本的应用程序或库版本。
因此，我认为REST API没有什么不同，并允许您的用户一直只能使用一个特定的API版本。
答案 1 :(得分：1)
如果您在 api.domain.com 或 domain.com/api 上拥有API，则消费者希望每种资源都具有相同的行为，特别是在您＆＃39时;处理请求和响应标头以及数据格式化。 然后，如果您在 api.domain.com/v1 上有一个行为并且您要更改它，则应将所有api资源升级到新行为并将版本更改为 api.domain的.com / V2
即使你是一个敏捷团队，我认为只发布版本v2中API的一个资源以及版本v1上的所有其余API，使用不同的格式化和请求/响应头只是在你的API消费者中造成一种不必要的混淆，也许你应该坚持到公开发布之前所有内容都要更新，如果不是一个选项，可能会将其作为/ beta发布就足够了。
如果您认为可以在同一版本中管理和发布所有资源，则应考虑对资源进行版本控制，而不是整体考虑API：
这种方法无法解决这个问题，因为从长远来看处理同一个api中的不同行为可能很复杂，但至少你把这个混乱的期望与你的API的消费者。
由于维护API的不同版本也可能会阻碍开发速度，我宁愿将新资源作为beta发布，直到可以发布新的API版本为止。