it does not seem to be a stretch to suggest adding a new qualifier: “text/plain; v=1.0″, etc. The absence of a version parameter can be treated as equivalent to asking for the most recent version.

The idea of using a version media type parameter is probably workable. However, I disagree with your idea regarding handling the absence of such a parameter. The default value for such a parameter would have to be to be “most compatible” version available. In most cases that means the oldest version.

Consider the following scenario. You deploy some service. A third party writes an application that acts a consumer of the service, but they do not include an explicit version parameter. A few months after they have finished work and moved on to something else you deploy a new version of the service. Now, suddenly, this external application stops working for no particularly obvious reason.

One core principle of versioning must be that any request that works in one version of the API will, in all future versions of the API, either a) continue to work in a compatible way, or b) fail with an explicit version compatibility error.

It seems that standard MIME types can be used along with additional ‘q-type’ values (’v’ values?). Since the idea here is to create new media types anyway (application/vnd….) it does not seem to be a stretch to suggest adding a new qualifier: “text/plain; v=1.0″, etc. The absence of a version parameter can be treated as equivalent to asking for the most recent version.

I do have some thought on how this versioning approach relates to standard formats. However, I have not worked in an environment where I have needed to do that so my thoughts are not fully formed yet.

I will try to write those up and publish them soon.

I am not fond of the putting the version information in a parameter on the MIME type. (MIME type parameters are not specific to HTTP 1.1, but rather are a general feature of MIME media types.) The use of a parameter implies to me that the server can provide a reasonable default value for that parameter. I suppose you can do this for versions but it leads to some unfortunate outcomes.

For example, if I support 3 different versions of some format and I
get a request for ‘application/vnd.myformat’ what version should I
return? From a safety stand point I would have to return the oldest
(i.e. least preferred) version because there might be clients out
there that only support that version of the API. Unfortunately, that
is probably the MIME type that will be used when newcomers are
exploring the interface. So you are forced to encourage the use of
the least preferred API available.

This same parameter can be seen in other RFCs and some Apache documentation too.