content negotiation and versioning

Hello!

This is a great question, and an interesting one as well.

As I'm sure you're aware, there are quite a few different ways to handle versioning, and content negotiation is indeed one of them.

First thing, it depends on which version of the spec you use. In 2.0, there's pretty much no way of describing that. In 3.0, there is a way to do what you want - but only in part.

Content negotiation applies to the payloads - either of the request, or the response. In the request, the consumer tells the producer what they're sending using the `Content-Type` header, and at the same time it asks the producer for a specific content reply using the `Accept` header. When the producer sends a reply, they'll use the `Content-Type` header in turn to describe what it is sending.

So where's the catch? The `Accept` header is a request, but the the producer doesn't have to comply. If it doesn't know how to produce the requested media type, it's perfectly legal for it to return a different one. As such, there's no strong correlation between the request media type and the response media type.

Furthermore, as mentioned above, the media type only impacts the content of the payload, not any other parameters. So in effect, there's nothing to make that conditional expectation that if you want a specific media type response (in your case a specific version), you'd have to send such and such query/header/path parameters.

At the moment, the specification does not allow you to define dependencies between different request parameters and a specific response, for the same given path. There are discussions to enable something like that in future versions, but nothing concrete is available.