最佳实践 - REST API 版本控制：物理存储源代码的位置和方式答案

【问题标题】：Best Practice - REST API versioning: Where and How to physically store source code最佳实践 - REST API 版本控制：物理存储源代码的位置和方式
【发布时间】：2016-02-05 01:11:57
【问题描述】：

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

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

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

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

问题：可版本化的 REST API 的源代码应该是什么样的？

很高兴拥有：

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

我能想到的可能答案：

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

命名空间：namespace 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

【问题讨论】：

不幸的是，这个问题似乎过于笼统，而且过于依赖语言/技术。
如果您指定一种语言（和适用的框架），您可能会得到具体的答案。
这还取决于在较新版本中进行了哪些更改。应用程序逻辑是否正在更改（例如，您的控制器、视图、将电子邮件/日志插件替换为另一个和其他基础设施设置），还是域逻辑更改（或两者兼而有之）？新版本多久发布一次？ api 仅供内部使用（您和您的团队），还是外部应用程序可以使用它？如果是外部的，如果有人想总是向最新版本发送请求怎么办？我知道这是很多问题，但不同的场景需要不同的方法。

标签： web-services api rest design-patterns namespaces

【解决方案1】：

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

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

【讨论】：