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

Question

我的问题不关于 REST API URI设计的最佳做法。
我自己决定，我将采用以下方法：

  

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

我对如何设计实际源代码更加好奇，以便轻松扩展更多版本的API。

我们假设我们已经为您喜爱的编程语言使用了经典的MVC框架。
我们的API工作正常，但我们希望添加＆amp;更改不向后兼容的功能。我们确实考虑过一个很好的URI设计，但没有考虑我们的代码应该如何看待，以便与不同的API版本很好地协作。废话..现在怎么办？

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

很高兴：

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

我能想到的可能答案：

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

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

1. 不同的项目

将https://theserver.com/api/v1/whatsoever指向项目 1
并https://theserver.com/api/v2/whatsoever投射 2

Answer 1

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

基于上面的答案，我会将API版本保存在我的存储库中的不同分支中。一个代码库，每个版本有多个分支。第一个分支对应于v1，它是稳定的，只接收修复。这里没有积极的发展。第二个分支对应于具有所有新功能的v2。