title: Rest Api url versioning scheme : Resource vs Service
body: <p>In our application we have adapted URI versioning scheme.</p>
  
  <p>Eg: server.com/v2/resource1</p>
  
  <p>Now there are two school of thought in the team:</p>
  
  <ol>
  <li><p>We should not expose resource level version to client, instead we should give one version to them. If they call  /v2/resource1 and v2 is not present for resource1 then we should reroute the request to /v1/resource1 internally.</p></li>
  <li><p>We should expose resource level versioning to client. If the call /v2/resource1 and v2 is not present for resource1 then we should send simple 404 error response to client.</p></li>
  </ol>
  
  <p>The benefit of the first approach is that client doesn’t have to worry about granular level of versioning. But this approach stops us from incremental refactoring of the end points as that will break backward compatibility, as once we expose v2, for client each resource is at v2 version.</p>
  
  <p>The second approach gives us better control over incremental refactoring and clear understanding of the resource version from client perspective as well.</p>
  
  <p>Thoughts?</p>