title: How to manage the logic behind the API versioning?
body: <p>I want to identify what might be considered as a best practice for URI versioning of the APIs, regarding the logic of the back-end implementation.</p>
  
  <p>Let's say we have a java application with the following API:</p>
  
  <pre><code>http://.../api/v1/user
  Request:    
      {
        "first name": "John",
        "last name": "Doe"
      }
  </code></pre>
  
  <p>After a while, we need to add 2 more mandatory fields to the user API:</p>
  
  <pre><code>http://.../api/v2/user
  Request:    
      {
        "first name": "John",
        "last name": "Doe",
        "age": 20,
        "address": "Some address"
      }
  </code></pre>
  
  <p>We are using separate DTOs for each version, one having 2 fields, and another having 4 fields.</p>
  
  <p>We have only one entity for the application, but my question is how we should handle the logic, as a best practice? Is ok to handle this in only one service?</p>
  
  <p>If those 2 new fields "age" and "address" would not be mandatory, this would not be considered a breaking change, but since they are, I am thinking that there are a few options:</p>
  
  <ul>
  <li>use only one manager/service in the business layer for all user API versions (but the complexity of the code in that only one manager will grow very much in time and will be hard to maintain)</li>
  <li>use only one manager for all user API versions and also use a class as a translator so I can make compatible older API versions with the new ones</li>
  <li>a new manager/service in the business layer for each user API version</li>
  </ul>
  
  <p>If I use only one manager for all user API versions and put there some constraints/validations, V2 will work, but V1 will throw an exception because those fields are not there.</p>
  
  <p>I know that versioning is a big topic, but I could not find a specific answer on the web until now.
  My intuition says that having a single manager for all user API versions will result in a method that has nothing to do with clean code, and also, I am thinking that any change added with a new version must be as loosely coupled as possible, because will be easier to make older methods deprecated and remove them in time.</p>