Using separate directory for each version of the API

Question

I'm planning to create an API with Laravel framework. And there may be multiple versions of the API if I continue developing it, like: v1, v2, v3, and so on.

And instead of having only one copy of Laravel framework and versioning the API inside it by creating different directories for each version, I'm thinking of creating a completely separate copy of Laravel framework for each version of the API.

For example, suppose this is the URL of the API: website.com/api, I'm thinking of creating a directory called v1 inside that api directory, and put a complete copy of Laravel in it. And later when I need to create a new version of the API, I will create another new directory called v2 beside v1 and put a new complete and separate copy of Laravel in it, and so on.

This way, when I want to access version 1 of the API, I will access this URL: website.com/api/v1 and when I want to access version 2, I will access website.com/api/v2.

My question: Is this a bad idea? And what are the disadvantage of this approach?

---

Edit:

Why did I think of this approach?

Because I thought of the following points:

• What if I wanted, someday, to create a new version of the API with a PHP framework other than Laravel.
• What if I wanted, someday, to create a new version of the API with a programming language other than PHP.
• What if I wanted, someday, to upgrade to a newer version of Laravel and that version has significant changes to the version that the API was originally created with.

Answer 1

I believe it's a bad idea - heaps of duplicate code, duplicate maintenance and absolutely no advantages.

Build for the Current Use Case

First of all:

You need to build technology to meet the current use case (and very near future)

So many CTOs / technology architects get it wrong by sometimes thinking too much into the future. What if my volume increases 1000x? Should I use a big data stack? No, certainly not unless you anticipate it happening in the next 3 months!

Disadvantages of your approach

1. Code duplicity: You would end up duplicating so much code - your Eloquent models, business logic, authentication, middleware, etc.
2. Maintenance & Other Overheads: Depending on your tech stack, maintenance would also be duplicated. For e.g. imagine running Artisan commands on multiple apps for a simple config cache refresh. Not to mention separate upgrades on dependencies, hardware resources, etc.

Advantages

There are no apparent advantages of your approach. Let's look at the specific questions that drove you towards this architecture:

1. What if I wanted, someday, to create a new version of the API with a PHP framework other than Laravel?

Let's say you currently have 3 versions and you want to create version #4 on a different framework. Well, you can still have the first 3 versions on a single Laravel app and the 4th version on a different app / codebase. If you already have 3 existing versions, there's no reason to have them as separate Laravel apps

2. What if I wanted, someday, to create a new version of the API with a programming language other than PHP.

Well, the same applies here as well. You can always have different apps for future versions in different languages if such situations arise

3. What if I wanted, someday, to upgrade to a newer version of Laravel and that version has significant changes to the version that the API was originally created with.

Minor versions are backward compatible in Laravel. So, if you upgrade from say Laravel 5.1 to 5.5, there should be no breaking changes. For major ones, you can choose different apps (if required) but really, even major version upgrades may not be a challenge. Of course, you can use tools such as Laravel Shift to make upgrading easy for you