Best Practices and How to support different versions of REST APIs in C# wrapper on client-side

Question

I have written a C# wrapper to support our company project's REST APIs. However, these APIs are changing now - in terms on URL (may introduce version number in URL) and data objects it expects and returns back.

I would like to know what would be the best practice on supporting different versions of REST APIs in my c# wrapper.

And how should I do it - in terms of code design and class definitions - so that one wrapper can work seamlessly with different versions of API - and it should be extensible also - so that any newer version of APIs in future can also be easily supported.

The c# wrapper I have written is consuming our web service APIs. I am already using RestSharp client to consume our web service APIs in c# wrapper.

Answer 1

There's a subtle weirdness to what you are asking. Let me reiterate what you have stated:

1) There are multiple versions of the same service at your organization. Perhaps they are established like Bob suggested, /current/api... /v1/api... /v2/api... etc. Or perhaps some other pattern.

2) You want a single C# library to be aware of each of the different versions.

It's this second part that is strange. Normally a client-side library would target a specific version only. It would be the server's responsibility to make sure that new versions of a service were either backwards compatible with old versions, or isolated on a new url.

Ask yourself this - if you were to go ahead and build this library that was aware of multiple versions of the same service, how would it look to the consumers of your library? Would they have to specifically tell you which version to use? That's not a concern I would expect to have to be aware of.

var client = new MyClient();
client.DoSomething();   // Makes sense    
client.DoSomethingV2(); // Huh?

Answer 2

Set up API versions, keep your current version as say version 1 and then add a v2 something like

/current/api?id=x....
/version2/api?id=x...

This allows you to update your api to support new functionality, and then you can set up a sunset plan for your out dated versions.

This way you can let your customers move over to your new system without it being an emergency.