最佳实践- REST版本控制:物理存储源代码的位置和方法
我的问题是而不是关于REST设计的最佳实践。
我自己决定，我将使用以下方法：
我更感兴趣的是，如何提前设计实际的源代码，以便轻松地扩展具有更多版本的。
让我们假设我们已经为您最喜欢的编程语言使用了经典的MVC-Framework。
我们的API运行良好，但我们希望添加和更改不向后兼容的功能。我们确实考虑过一个很好的URI设计，但是没有考虑我们的代码应该如何与不同的API版本很好地工作。废话..。现在怎么办？
问:可版本REST的源代码应该是什么样的呢？
很高兴有：
- 不要混淆不同的版本
- 还是最好的干燥方法
- 别再重新发明轮子了
- 将被延长
我能想到的可能答案：
- 相同的项目-不同的名称空间和子文件夹
命名空间：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
回答 1
Stack Overflow用户
发布于 2016-09-16 15:25:54
这是我的逻辑：-首先，我们需要回答“为什么我们需要版本控制？”--如果我们能够以向后兼容的方式扩展API，那么我们就不需要版本控制(所有应用程序和服务都将使用相同的API，不需要任何更改)。如果我们不能提供向后兼容的API，那么我们需要引入下一个版本的API。这将允许所有应用程序和服务顺利地迁移到新版本，而旧版本正在工作。经过一段时间(一年)后，第一个版本可以被淘汰和停止。
因此，根据上面的答案，我会将API版本保存在存储库中的不同分支中。一个代码基，每个版本有多个分支。第一个分支对应于v1，它是稳定的，只接收修复。这里没有积极的发展。第二个分支对应于具有所有新特性的v2。
https://stackoverflow.com/questions/33523590
复制相似问题
腾讯云开发者
