> Is media type the preferred model for versioning rather than URL? Well I guess the answer might be influenced by the choice between a single over-arching media type and many fine-grained types. Because if the former, then specifying the version in the Content-Type would imply the versions of all fine-grained types are rev'd in lock-step. Which may potentially be awkward to maintain. > I could also see /v1/xxxx and /v2/xxxx as means of supporting incompatible versions. Might this approach lead to a higher likelihood of knowledge of the URI structure leaking out to the client side? Cheers, Eoghan <div class="gmail_quote">On 15 April 2010 13:26, Bryan Kearney <<a href="mailto:bkearney@redhat.com">bkearney@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On 04/15/2010 08:21 AM, Eoghan Glynn wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > A single media type to describe all documents returned by the API Interesting question. My initial reaction is that the single application/vnd.com.redhat.rhevm.api+xml media type may indeed be better than a proliferation of more fine-grained types, as really what we're trying to capture here is the "application protocol", which could be thought of in a holistic sense as applying to the entire API. Whereas the individual fine-grained type could be inferred from the entity-body in any case, from say the schema identified in the root xmlns attribute or whatever. So this doesn't need to be necessarily specified in the Content-Type header. A single media type may well be easier to standardize also, if we ever need to evolve it out of the vendor-private space. </blockquote> </div> Is media type the preferred model for versioning rather than URL? I could also see /v1/xxxx and /v2/xxxx as means of supporting incompatible versions. -- bk </blockquote></div>