1

I'm working with ASP.NET core web API project, where I have 8 controllers, multiple DTOs being used for request and response and mappers to map models(also used in the web app) with DTOs.

Recently, we have started with versioning, for that, we're referring to the best practices: API-Version-Conventions. Here is the project structure we have so far:

MyProject
└ API
  ├─ v1
  │  └ Controllers
  |  L Models
  ├─ v2
  │  └ Controllers
  |  L Models
  └─ v2_5
     └ Controllers     
     L Models

But in this case, we need to copy the same code again and again, even if the release is minor. So is this good practice or is there any other way around?

2

This is bad practice.

The problem with the structure is that your 'versions' are not release versions anymore.

When you added version 2 to your API you deployed v1 and v2 together. The original deployment for v1 was presumably overwritten.

Best practice is to use your version control for versioning your code, and to deploy a new version completely separately from the old version on new virtual machine.

Then you route the network traffic to the new or old version using your network infrastructure not your websites code.

That way, you don't touch the old version at all when you deploy the new one. there is no possibility of a bug being introduced to the old version, as you haven't changed it at all.

If you need to roll back, its simply a matter of routing the traffic to the old boxes again. They are still there working away as normal.

  • Thanks, @Ewan for your answer! what you're trying to say is "if I have 10 different versions I need to run 10 instances separately" but then what is actual use of versioning in api here? – Div Dec 7 '18 at 17:13
  • same as any versioning, so the old clients dont break – Ewan Dec 7 '18 at 17:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.