Versioning is hard. Versioned APIs are very hard. I'm in an especially tricky spot because we've got customers that might refuse to upgrade our product for years and years, if ever.
Two approaches I've taken, with a blogpost worth of thoughts on them:
1. Every version is a whole new database/webserver stack. You shut the oldest one down when the last customer migrates off it. The bloat is real, but it's dead simple and it works.
2. A single database with a webserver that exposes all the versions. The contract is that the database shall not undergo destructive migrations. Only additive migrations. Or if you must, modify schema in a way that you can deterministically generate every previous API's view. Again, discard older versions when the last customer has been migrated off.
I'm sure you can immediately smell some problems with either of these approaches. Sacrifices are definitely made.
Every version is a whole new database/webserver stack. You shut the oldest one down when the last customer migrates off it. The bloat is real, but it's dead simple and it works.
That means data is different between API versions?
Yes. But that works. Becuase a customer's data lives in only one version. When the customer upgrades their data gets migrated. Weird. Dead simple. Works.
Two approaches I've taken, with a blogpost worth of thoughts on them:
1. Every version is a whole new database/webserver stack. You shut the oldest one down when the last customer migrates off it. The bloat is real, but it's dead simple and it works.
2. A single database with a webserver that exposes all the versions. The contract is that the database shall not undergo destructive migrations. Only additive migrations. Or if you must, modify schema in a way that you can deterministically generate every previous API's view. Again, discard older versions when the last customer has been migrated off.
I'm sure you can immediately smell some problems with either of these approaches. Sacrifices are definitely made.