On Wed, Jan 30, 2013 at 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.
I've no idea about these changes and how and why they were made? Comment or advise anyone? I've been maintaining and working on the api layer about past two months now and I feel this is the layer which the world talks to and my aim is to make sure we keep minimal damages to projects who are based on top of CloudStack if that requires us to deprecate it and adopt something REST-ful or standardized. This is for future of course, I still want feedback and info on the changes as Adrian mentions. > > -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-12910434>.
