REST controllers should alias unversioned URIs to the highest supported version in the server

[JoeCap08055]

Description

As a client of Gateway, I want to be able to always reference the latest API at a fixed address. Currently, as new versions of Gateway are deployed, I must update my calls to include the correct version of endpoints (ie, GET account/v1/handles//{msaId}. While this is useful for maintaining backward compatibility, for clients that always want the latest version of the resource/endpoint, I should be able to retrieve simply GET account/handles/{msaId}, which would directly me to the latest versioned API of that resource.

[wilwade]

I'm not sure this is a desirable feature. It would work, but the point of a version is that it has breaking changes. So why would we want to alias to an endpoint that we know will break?

[JoeCap08055]

I'm not sure this is a desirable feature. It would work, but the point of a version is that it has breaking changes. So why would we want to alias to an endpoint that we know will break?

What's "standard" behavior, though? We've opted to use an in-route versioning schema; ie the API version is encoded in the route path itself. Currently that forces a client to be version-specific in every request. Other popular versioning schemas put the route information in the request header, or as a query parameter--both optional, and if missing, usually handle with a default implementation (usually the latest API version handler). I was thinking we should offer the same type of approach.

[wilwade]

Hmm... I can see perhaps supporting a header or such, but I don't understand the defaulting. Since you have to get the params correct and manage the response correctly, you cannot do that without knowing the version.

[wilwade]

Not for now