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>.
