I haven't really found a decent/future-proof way to version methods in my WebAPI.  This is what I typically do now, but it can get confusing and hard to trace if it gets a bit large (I'll end up [OBSOLETE]-ing the older ones as time goes on).   Has anyone come up with a more elegant or manageable option to versioning WebAPI in C#/NET.public class CoreController : ApiController    {    [HttpGet][Route(~/services/core/test/v{_version})]    public IHttpActionResult returnTest(int _version) {        try {             switch (_version) {                case 2:                    return Ok(returnTest_v2());                case 1:                default:                    return Ok(returnTest_v1());            }        } catch { return NotFound(); }    }    public string returnTest_v1() { return SAMPLE_V1; }    public string returnTest_v2() { return SAMPLE_V2; }}
REST API Versioning in C# WebApi
c#
Actually, since you're already using custom routes this is a pretty simple fix.  It has to do with the route structure, which right now isn't perfect, but we can fix it.from the sample code, i gather that your api follows this pattern:{category}/{resource}/{id}/v{ersion}Which is fine, the problem is its creating those branches in your code which i can't imagine are very fun to maintain or add, though I'll have to admit it'd be convenient to have the previous version's code right there.Anyway, consider moving around a few things to do this:v{ersion}/{category}/{resource}/{id}and separate the methods out into each route on its own. So the example method's signature would become:[HttpGet][Route(~/v1/services/core/test/)]public IHttpActionResult returnTestv1() { //Remember each method has to be uniquely named in ASP.NET[HttpGet][Route(~/v2/services/core/test/)]public IHttpActionResult returnTestv2() {You'll note i also didn't use them as a variable, to 'bake in' their identity. So, while this doubles (triples, quadruples...) the number of methods for each endpoint, there's a few upsides:1) Compatibility - Let's say you make this a public API.  I write something for v1, i can keep using v1 until you take it down (my company, for example, maintains v4 and v5, and retired v3 and earlier.  Blizzard still supports their original v1 of the Warcraft API and is now on v3 or something).  This also means you can clearly modify the functionality of certain endpoints between versions and not confuse existing client programs. I know in an SIS API i programmed against once, the function of GET /student/{id} changed drastically between v1 and v2.2) Maintainence - With this new structure, you can't confuse where a bug is occurring.  Better, if you decide to only add a change to output or some logic on the way in, you can still call the old method and keep things behaving consistently.