How do multiple versions of a REST API share the same data model?

Question

There is a ton of documentation on academic theory and best practices on how to manage versioning for RESTful Web Services, however I have not seen much discussion on how multiple REST APIs interact with data.

I'd like to see various architectural strategies or documentation on how to handle hosting multiple versions of your app that rely on the same data pool.

For instance, suppose you make a database level destructive change to a database table that causes you to have to increment your major API version to v2. Now at any given time, users could be interacting with the v1 web service and the v2 web service at the same time and creating data that is visible and editable by both services. How should this be handled?

Answer 1

Most of changes introduced to API affect the content of the response, till changes introduced are incremental this is not a very big problem (note: you should never expose the exact DB model directly to the clients).

When you make a destructive/significant change to DB model and new API version of API is introduced, there are two options:

1. Turn the previous version off, filter out all queries to reply with 301 and new location.
2. If 1. is impossible to need to maintain both previous and current version of the API. Since this might time and money consuming it should be done only for some time and finally previous version should be turned off.

What with DB model? When two versions of API are active at the same time I'd try to keep the DB model as consistent as possible - having in mind that running two versions at the same time is just temporary. But as I wrote earlier, DB model should never be exposed directly to the clients - this may help you to avoid a lot of problems.

Answer 2

I have given this a little thought...

One solution may be this:

Just because the v1 API should not change, it doesn't mean the underlying implementation cannot change. You can modify the v1 implementation code to set a default value, omit the saving of a field, return an unchecked exception, or do some kind of computational logic that helps the v1 API to be compatible with the shared datasource. Then, implement a better, cleaner, more idealistic implementation in v2.

Answer 3

when you are going to change any thing in your API structure that can change the response, you most increase you'r API Version.
for example you have this request and response:
request post: a, b, c, d res: {a,b,c+d}

and your are going to add 'e' in your response fetched from database.
if you don't have any change based on 'e' in current client versions, you can add it on your current API version. but if you'r new changes are going to change last responses, for example: res: {a+e, b, c+d} you most increase API number to prevent crashing.

changing in the request input's are the same.