QUOTE(life4 @ Feb 26 2021, 01:08 AM)
yea if a completely different logic then i think surely no problem doing like that, what i am asking like 80 percentage are similar . we all know best way is to deprecte api but let says you have 10k client , impossible like you inform everyone to ask them to change though like you said gradually deprecated the api
or like mobile app you might rollout the api but some still using old app version using old api
Well that's more related to how would you handle your client relationship for SLA and EOL. Again, you generally don't arbitrarily roll new version of API overnight, right ? Even if you do, that does not impact your existing client or user of the existing API.
Unless your API is open to the public, say for example, a weather API that you return the current weather given an zip code / post code and you didn't require any keys or authentication to use your API, then I can understand you will have an issue informing your user that you are deprecating the API, but that's a given with public facing API, it's provided as-is basis, the best you can do is to put a note on your site and say, hey this api will be deprecated by Z date, please use our new API.
For mobile App, you can trigger an update and force all older than x version to upgrade, right ?
Of course, you reuse as much as possible since it's been tested so it makes sense to use it more. So how reusable your code depends on you, right ?
If it's 80% similar but it's tightly coupled, you will be carrying all the baggage along with 80% similarity.
All in all, if you are adamant about avoiding code duplicate, just don't version the API and just keep adding function / feature to it. You don't have to maintain multiple version and worry about code duplication but carry the risk of breaking existing. In the end, you will have to decide, which works for you and what trade off you are willing to accept. I don't think there is ever a right or wrong answer.