On 04/13/2010 12:44 AM, David Lutterkort wrote:
On Mon, 2010-04-12 at 23:20 +0100, Eoghan Glynn wrote:
>
>> 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)
Finegrained versioning like that will quickly devolve into a thicket of
differing versions that are very hard to pick apart.
I'm with David on this one. Including a version number seems like an
overdesign to me and reminds me of the complexities of SOAP.
The detailed schema specification seems similarly overdesigned to me
(i'd just take "text/xml"), but less so than the version number.
Regards,
Geert
I'd much prefer an approach where the XML that is sent back is backwards
compatible; that means that as versions progress, old clients will still
find what they expect to see, though the XML may contain additional
'stuff' that old clients will just ignore.
David
_______________________________________________
rhevm-api mailing list
rhevm-api(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhevm-api
--
Geert Jansen, Product Marketing Manager EMEA
Red Hat S.r.L. T: +39 348 1980079
Via Antonio da Recanate 1 E: gjansen(a)redhat.com
Milan 20124, Italy
Calculate your virtualization TCO at bit.ly/7CKhUm