db0@lemmy.dbzer0.com to Programmer Humor@programming.dev · 14 hours agoThat shadowy placelemmy.dbzer0.comimagemessage-square30fedilinkarrow-up1763arrow-down10
arrow-up1763arrow-down1imageThat shadowy placelemmy.dbzer0.comdb0@lemmy.dbzer0.com to Programmer Humor@programming.dev · 14 hours agomessage-square30fedilink
minus-squarebleistift2@sopuli.xyzlinkfedilinkEnglisharrow-up10·9 hours agolocation /old_api { redirect /new_api } (can’t be bothered to check the syntax).
minus-squareCosmicTurtle0@lemmy.dbzer0.comlinkfedilinkEnglisharrow-up12·9 hours agoIf you have a major version change, it means that old API calls will break against the new API, assuming they are accurately following semver.
minus-squarebleistift2@sopuli.xyzlinkfedilinkEnglisharrow-up7·9 hours agoYou’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
minus-squareLongpork3@lemmy.nzlinkfedilinkarrow-up2arrow-down1·6 hours agoA translation layer could be used, no? Check api version, translate any v1 specific calls into their v2 counterparts, then submit the v2 request?
minus-squareCosmicTurtle0@lemmy.dbzer0.comlinkfedilinkEnglisharrow-up1·4 hours agoThis isn’t really efficient because when v2 gets updated now you have to update the translation layer as well. Any improvements you made in v2 would likely not translate. Essentially the best way is to provide users with an incentive to switch. Perhaps a new feature or more requests.
(can’t be bothered to check the syntax).
If you have a major version change, it means that old API calls will break against the new API, assuming they are accurately following semver.
You’re absolutely right. In my mind “feature parity” got garbled into “backwards compatibility”.
A translation layer could be used, no? Check api version, translate any v1 specific calls into their v2 counterparts, then submit the v2 request?
This isn’t really efficient because when v2 gets updated now you have to update the translation layer as well.
Any improvements you made in v2 would likely not translate.
Essentially the best way is to provide users with an incentive to switch. Perhaps a new feature or more requests.