The ability to bump the version in future if we really need to is
what
most appeals to me e.g.
application/vnd.com.redhat.rhevm.api.VM+xml;version=1.1
Yeah, I like the idea.
We could even go nuts with the version property and allow a client specify a
range in the Accept header, following the OSGi version-constraint pattern.
Assuming it's implicit that only backward compatible changes are made to the
schema types within a minor version rev.
So suppose a client wanted to indicate it understands version 1.1 or later,
but not anything in the 2.x line, it could express this constraint as:
Accept: application/vnd.com.redhat.rhevm.api.VM+xml;version=[1.1,2.0)
Cheers,
Eoghan
On 12 April 2010 21:44, Mark McLoughlin <markmc(a)redhat.com> wrote:
> On Fri, 2010-04-09 at 21:22 +0100, Eoghan Glynn wrote:
> > But here's another slightly related point, how about indicating a more
> > informative type than "application/xml" via the type attribute, say
> > something vendor-specific like
"application/vnd.com.redhat.rhevm.api+xml"
> or
> > even "application/vnd.com.redhat.rhevm.api.VM+xml"?
> >
> > The reason being that this would make it absolutely explicit we're not
> just
> > talking plain ol' XML, but rather an application-specific hypermedia
> type.
> > This type may also be explicitly advertized in the Content-Type header of
> > the response when the link is dereferenced, which kinda makes our
> > application protocol manifest at the standard HTTP level, as opposed to
> just
> > embedding this same info in the entity-body (say in the root namespace of
> > the XML payload).
>
> What's that they say about great minds thinking alike? I have this on
> the TODO list already:
>
>
https://fedorahosted.org/rhevm-api/wiki/RestApiTodo
>
> Should we define a versionable media type rather than just using e.g.
> application/xml
>
The ability to bump the version in future if we really need to is
what
most appeals to me e.g.
application/vnd.com.redhat.rhevm.api.VM+xml;version=1.1
>
> See p115 in bburke's book
>
> Cheers,
> Mark.
>
>