3 ms·
> you will have people relying on every single version of your API If you put the API version into the access token, you can bump people upwards when they refr
by zimpenfish 3y ago
> you will have people relying on every single version of your API
If you put the API version into the access token, you can bump people upwards when they refresh / restart, then delete the old API when the token expiry comes around.
> Second, this micro-versioning may cause compatibility issues.
If you control the FE deployment, this isn't a problem. If you don't want to sync up the FE/BE deployments -- say it's an iOS app and you don't want to do an app store push every time you deploy to BE) -- you could use a backend-for-frontend layer or WAF which proxies to the correct backend version (based on the access token version ^ as up there.)
- BoppreH 3y agoI was thinking of more genral API versioning, not just for web services. Like example.com/api/v2/ on steroids. And what happens with services sharing stateful resources? When the database schema is at version 10, a service expecting version 2 would be trouble, no?
- zimpenfish 3y ago> When the database schema is at version 10, a service expecting version 2 would be trouble, no? There are ways around that - views, functions, triggers, etc. (have had to do similar twice this year.) But it can be a faff, definitely.