最佳实践 - REST API版本控制:在何处以及如何物理存储源代码

Question

我的问题不是关于REST API URI设计的最佳实践.
我已经决定自己,我将使用以下方法:

https://theserver.com/api/v1/whatsoever

我对如何提前设计实际源代码更加好奇,以便用更多版本轻松扩展 API.

假设我们已经为您喜欢的编程语言使用了经典的MVC-Framework.
我们的API工作正常但我们想要添加和更改不向后兼容的功能.我们确实考虑过一个很好的URI设计,但没想到我们的代码应该如何看待,以便与不同的API版本很好地协作.废话..现在怎么样？

问题:可版本化REST API的源代码应该如何？

很高兴有:

1. 不要混淆不同的版本
2. 仍然最好使用DRY
3. 不要再重新发明轮子
4. 将延长

我能想到的可能答案:

1. 相同的项目 - 不同的命名空间和子文件夹

命名空间:namespace App\Http\Controllers\v1\Users;
文件夹: {root_folder}\app\Http\Controllers\v1\Users\UserLoginController.php

2. 不同的项目

指向https://theserver.com/api/v1/whatsoever项目1
和 https://theserver.com/api/v2/whatsoever项目2

Answer 1

这是我的逻辑： - 首先我们需要回答“为什么我们需要版本控制？”的问题。- 如果我们能够以向后兼容的方式扩展我们的 API，那么我们就不需要版本控制（所有应用程序和服务都将使用相同的 API，不需要进行任何更改）。- 如果我们不能提供向后兼容的 API，在这种情况下我们需要引入下一个版本的 API。这将使所有应用程序和服务能够在旧版本正常运行的同时顺利迁移到新版本。一段时间（一年）后，第一个版本可能会被废弃并停止。

因此，根据上面的答案，我会将 API 版本保留在我的存储库中的单独分支中。一个代码库，每个版本有多个分支。第一个分支对应于 v1，它是稳定的并且仅接收修复。这里没有积极的开发。第二个分支对应于 v2，它具有所有新功能。