[rest-practices] Media types

Eoghan Glynn eoghan.glynn at gmail.com
Thu Apr 15 12:53:16 UTC 2010


> 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


On 15 April 2010 13:26, Bryan Kearney <bkearney at redhat.com> wrote:

> On 04/15/2010 08:21 AM, Eoghan Glynn wrote:
>
>>
>>
>>  > 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.
>>
>>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rest-practices/attachments/20100415/232668d4/attachment.htm>


More information about the rest-practices mailing list