我计划用Laravel框架创建一个API。如果我继续开发它，可能会有多个版本的API，比如：v1、v2、v3，等等
我想为每个版本的API创建一个完全独立的Laravel框架副本，而不是只有一个Laravel框架副本，并通过为每个版本创建不同的目录来控制其中的API版本
例如，假设这是API的URL:website.com/API，我正在考虑在该API目录中创建一个名为v1的目录，并在其中放置一个完整的Laravel副本。稍后，当我需要创建新版本的API时，我将在v1旁边创建另一个名为v2的新目录，并在其中放置一个新的完整和单独的Laravel副本，依此类推
这样，当我想访问API版本1时，我将访问以下URL:website.com/API/v1，当我想访问版本2时，我将访问website.com/API/v2
我的问题：这是个坏主意吗？这种方法的缺点是什么
编辑：
为什么我会想到这种方法
因为我想到了以下几点：
- 如果有一天我想用一个PHP框架而不是Laravel创建一个新版本的API呢
- 如果有一天我想用PHP以外的编程语言创建一个新版本的API呢
- 如果有一天我想升级到更新版本的Laravel，并且该版本对最初创建API的版本有重大更改，该怎么办
我认为这是个坏主意——大量重复的代码，重复的维护，绝对没有好处
为当前用例构建
首先:
您需要构建技术来满足当前的用例（而且非常复杂）
（近期）
因此，许多CTO/技术架构师有时会因为对未来考虑太多而出错。如果我的音量增加1000倍怎么办？我应该使用大数据栈吗？不，当然不会，除非你预计它会在未来3个月内发生
您的方法的缺点
- 代码重复性：你最终会复制这么多代码——你雄辩的模型、业务逻辑、身份验证、中间件等等
- 维护与维护；其他管理费用：根据您的技术水平，维护工作也会重复进行。例如，想象一下在多个应用程序上运行Artisan命令以进行简单的配置缓存刷新。更不用说依赖项、硬件资源等的单独升级了
优势
你的方法没有明显的优点。让我们看一下推动您实现此体系结构的具体问题：
- 如果有一天我想用一个PHP框架而不是Laravel来创建一个新版本的API，会怎么样
假设您当前有3个版本，并且希望在不同的框架上创建版本4。好吧，你仍然可以在一个Laravel应用程序上拥有前3个版本，在另一个应用程序/代码库上拥有第4个版本。如果您已有3个现有版本，则没有理由将它们作为单独的Laravel应用程序
- 如果有一天我想用PHP以外的编程语言创建一个新版本的API呢
嗯，这里也一样。如果出现这种情况，您随时可以使用不同的语言为将来的版本提供不同的应用程序
- 如果有一天我想升级到更新版本的Laravel，并且该版本对最初创建API的版本有重大更改，该怎么办
次要版本在Laravel中向后兼容。所以，如果你从Laravel5.1升级到5.5，应该不会有突破性的变化。对于大型应用程序，您可以选择不同的应用程序（如果需要），但实际上，即使是大型版本升级也不是一个挑战。当然，您可以使用诸如Laravel Shift之类的工具来简化升级