Recommendations and ways to support different versions of the REST API in the client-side C # shell

Question

I wrote a C # wrapper to support our project's REST APIs. However, these APIs are now changing - in terms of the URL (may contain the version number in the URL) and the data objects that it expects and returns.

I would like to know what would be the best practice for supporting various versions of the REST APIs in my C # shell.

And how do I do this — in terms of developing code and class definitions — so that a single shell can work without problems with different versions of the API — and it must also be extensible — so that any newer version of the API can also be easily supported in the future.

The C # wrapper I wrote consumes our web services APIs. I already use the RestSharp client to use our web services APIs in the C # wrapper.

Answer 1

There is a subtle oddity to what you ask. Let me repeat what you stated:

1) There are several versions of the same service in your organization. Perhaps they are installed, as Bob suggested, / current / api ... / v1 / api ... / v2 / api ... etc. Or maybe another template.

2) You want one C # library to know each of the different versions.

This is the second part, which is strange. Typically, the client library is for a specific version only. The responsibility of the server must be to ensure that new versions of the service are either backward compatible with older versions or isolated on the new URL.

Ask yourself: if you were to get together and create this library that knew several versions of the same service, what would it look like for the consumers of your library? Should they specifically tell you which version to use? This is not a concern that I would expect to know about.

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

Answer 2

Configure API versions, save your current version as say version 1, and then add v2 something like

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

This allows you to update the api to support new features, and then you can set up a sunset plan for older versions.

Thus, you can allow your customers to switch to a new system without an emergency.