When you do want to maintain multiple simultaneous versions of an API that can be used simultaneously, then you might employ a SemVer style approach. Really, each version of the endpoint is addressed separately (as its own endpoint).
AWS has employed this strategy before when making significant changes to APIs. I believe DynamoDB is on version 2 for example.
I’d agree that versioning services this way is uncommon due to the expense of maintaining multiple simultaneous code stacks (which can be more than 2x the effort of one stack - see my other comment in this thread). But if client experience is paramount and/or migration is difficult then it may make sense.
Comments
When you do want to maintain multiple simultaneous versions of an API that can be used simultaneously, then you might employ a SemVer style approach. Really, each version of the endpoint is addressed separately (as its own endpoint).
AWS has employed this strategy before when making significant changes to APIs. I believe DynamoDB is on version 2 for example.
I’d agree that versioning services this way is uncommon due to the expense of maintaining multiple simultaneous code stacks (which can be more than 2x the effort of one stack - see my other comment in this thread). But if client experience is paramount and/or migration is difficult then it may make sense.