web-services - 最佳实践 - REST API 版本控制 : Where and How to physically store source code

Question

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

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

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

假设我们为您最喜欢的编程语言使用了经典的 MVC 框架。
我们的 API 工作正常，但我们想要添加和更改不向后兼容的功能。我们确实考虑过一个漂亮的 URI 设计，但没有考虑我们的代码应该如何设计才能与不同的 API 版本很好地配合。糟糕..现在怎么办？

问题:可版本控制的 REST API 的源代码应该是什么样子？

很高兴拥有:

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

我能想到的可能答案:

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

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

不同项目

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

Answer 1

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

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