I've reverted the commit which makes both xml and json responses to be consistent, to return version alongwith it. https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=summary
Regards. On Wed, Jan 30, 2013 at 2:23 PM, Min Chen <[email protected]> wrote: > Which version of 3.x do you have? We are aware of the addition of > cloudstack-version, Rohit made that change to be consistent with XML > output. But for the deployvirtualmachine vs deployvirtualmachineresponse > change, I checked CloudStack 3.0.x code, it is using > "deployvirtualmachineresponse". > > Thanks > -min > > On 1/30/13 1:06 PM, "Chip Childers" <[email protected]> wrote: > >>On Wed, Jan 30, 2013 at 3:56 PM, Rohit Yadav <[email protected]> >>wrote: >>> Did we change the response format to an envelop style? >>> >>> Cloudstack 3.x >>> deployvirtualmachineresponse.json : { "deployvirtualmachine" : >>>{"id":1234, >>> "jobid":50006} } >>> Cloudstack 4.x >>> new json response : { "deployvirtualmachineresponse" : >>> >>>{"id":"1cce6cb7-2268-47ff-9696-d9e610f6619a","jobid":"13330fc9-8b3e-4582- >>>aa3e-90883c041ff0"}, >>> "cloudstack-version": "4.1.0-SNAPSHOT" } >> >>It looks like there are two changes... The name of the returned >>object (deployvirtualmachine vs deployvirtualmachineresponse), as well >>as the addition of the cloudstack-version field. >> >>-chip >> >>> Forwarding comment from jclouds developer Adrian: >>> >>> ---------- Forwarded message ---------- >>> From: Adrian Cole <[email protected]> >>> Date: Wed, Jan 30, 2013 at 12:25 PM >>> Subject: Re: [jclouds] cloudstack renamed deployvirtualmachineresponse >>>in >>> version 4.1 (#1254) >>> To: jclouds/jclouds <[email protected]> >>> Cc: Bhaisaab <[email protected]> >>> >>> >>> @bhaisaab <https://github.com/bhaisaab> another note wrt the envelope >>>style >>> used in cloudstack. If you are looking to support multiple version >>> detection, it would be much easier on us and others to use http >>>mechanisms. >>> typically content mediation is done via headers, rather than wrapping >>> things in a thing that includes version and starts feeling like SOAP. >>> making a generator based on your style of doing versions is possible, >>>but >>> it wouldn't be reusable code. If there's good reason to deviate from >>>ReST >>> and other similar apis wrt Accept header and/or version headers, please >>> consider things that you are doing on your own, as making tools that >>>only >>> work with the cloudstack way isn't enough gain to even use the metadata >>> service you describe. for example, there are specs like HAL >>> http://stateless.co/hal_specification.html that at least have a chance >>>of >>> tooling support. Alternatively, you could go into the REST community and >>> pitch the way you do things and get others to adopt it. This could also >>> lead to tooling that isn't bespoke only to cloudstack. >>> >>> ‹ >>> Reply to this email directly or view it on >>> >>>GitHub<https://github.com/jclouds/jclouds/issues/1254#issuecomment-129104 >>>34>. >
